x-gzip-Token im Accept-Encoding-Header

413
NanoPish

Die Inhalts-Encoding-Seite des MDN-Web-Dokuments besagt, dass das x-gzip-Token ein Alias ​​für gzip im Content-Encoding-HTTP-Header ist.

Aber die Accept-Encoding-Seite erwähnt es nicht.

Gibt es eine Liste der Header nach Browserversionen oder Systemversionen, die x-gzip verwenden? Woher kommt dieser Alias?

Ist die Verwendung von x-gzip in Accept-Encoding legitim?

1

1 Antwort auf die Frage

1
grawity

Es ist legitim (naja, früher war es legitim) sowohl in der Nutzung als auch in der Spezifikation.

x- ist ein gebräuchliches Präfix für nicht standardmäßige (oder "noch nicht standardmäßige") Bezeichner, die häufig explizit von Protokollen zugelassen werden, oft eine De-facto-Konvention von Implementierern.

War x-gzipalso in HTTP / 1.0 weit verbreitet und bedeutete ursprünglich, dass das Format noch nicht in die offiziellen von IANA verwalteten Table Of Content Encodings eingetragen wurde (falls die Tabelle damals überhaupt existierte). Beispielsweise wurde Opera 4 oder 5 verwendet, um dieses Token zu senden.

Das gzipToken wurde seit HTTP / 1.1 zum Standard gemacht, und die HTTP / 1.1-Spezifikation besagt, dass dies x-gzipein akzeptabler Alias ​​für Kompatibilitätszwecke ist - es ist sicherlich nicht etwas, das MDN nur erfunden hat.

Der große Nachteil dieser Konvention besteht jedoch darin, dass die alte x-Version nach der Vereinheitlichung des Namens noch Jahrzehnte bestehen bleibt und Software beide unterstützen muss. Oft werden neu geschriebene Dokumente absichtlich die alten Aliasnamen weggelassen, um deren Verwendung zu verhindern. Siehe auch RFC 6648, in dem der Verlauf besprochen und sogar dieses genaue Token in Anhang B erwähnt wird .

Danke für deine Antwort. Diese RFC-Links sind nützlich und interessant. Sind Sie sicher, dass es in der Akzeptanzcodierung legitim ist, nicht nur in der Inhaltscodierung (wird dies von einer Quelle erwähnt?). Ich kann keine gängigen Browserversionen finden, die es senden, nur Crawler und Bots. NanoPish vor 5 Jahren 0
Alle "x-" Token sind "legitim" in dem Sinne, wie es das Protokoll erlaubt. Wenn eine bestimmte Codierung in der Content-Encoding von reply legitim ist, bedeutet dies, dass sie auch in der Accept-Encoding-Anforderung der Anforderung legitim ist (da der Server keine Codierung verwenden kann, die der Client nicht angefordert hat!). Gemeinsame Browser senden nicht mehr "x-gzip" - es ist ein Überbleibsel der fernen Vergangenheit. (siehe letzte Bearbeitung). grawity vor 5 Jahren 1
Wenn Sie spezifisch sein möchten, lesen Sie RFC 2616 oder RFC 7231, und beachten Sie, dass HTTP die Werte dieser Header nicht direkt definiert. Stattdessen definiert es eine Gruppe von "Content-Coding" -Token und einfach die Syntaxdefinitionen beider Header Referenz "Inhaltskodierung". Die Hauptquelle für erlaubte Token ist [das IANA-Register] (https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding), während Tabellen in MDN & c. sind sekundäre Quellen. grawity vor 5 Jahren 1
Korrektur: Ich glaube, ich habe falsch gesagt, dass HTTP explizit "x -..." -Token zulässt (obwohl es viele andere Protokolle gibt, die dies tun). Es erlaubt jedoch speziell 'x-gzip'. grawity vor 5 Jahren 1