Transfer-Encoding: gzip vs. Content-Encoding: gzip

Wie ist der aktuelle Stand der Dinge, wenn es darum geht, ob dies zu tun ist?

Transfer-Encoding: gzip

oder ein

Content-Encoding: gzip

Wenn ich Clients mit z. B. begrenzter Bandbreite erlauben möchte, ihre Bereitschaft zu signalisieren, eine komprimierte Antwort zu akzeptieren, und der Server das letzte Wort darüber hat, ob er komprimiert oder nicht .

Letzteres ist das, was zB Apaches mod_deflate und IIS tun, wenn Sie es für die Komprimierung sorgen lassen. Abhängig von der Größe des zu komprimierenden Inhalts wird dies zusätzlich ausgeführt Transfer-Encoding: chunked.

Es wird auch ein enthalten Vary: Accept-Encoding, das bereits auf das Problem hinweist. Content-Encodingscheint Teil der Entität zu sein, daher bedeutet das Ändern der Content-EncodingBeträge zu einer Änderung der Entität, dh ein anderer Accept-EncodingHeader bedeutet, dass beispielsweise ein Cache seine zwischengespeicherte Version der ansonsten identischen Entität nicht verwenden kann.

Gibt es eine eindeutige Antwort darauf, die ich verpasst habe (und die nicht in einer Nachricht in einem langen Thread in einer Apache-Newsgroup vergraben ist)?

Mein aktueller Eindruck ist:

• Transfer-Encoding wäre in der Tat der richtige Weg, um das zu tun, was meistens mit Content-Encoding durch vorhandene Server- und Client-Implementierungen gemacht wird
• Die Inhaltscodierung ist aufgrund ihrer semantischen Auswirkungen mit einigen Problemen verbunden (was sollte der Server tun, ETagwenn er eine Antwort transparent komprimiert?).
• Der Grund ist Chicken'n'egg: Browser unterstützen es nicht, weil Server dies nicht tun, weil Browser dies nicht tun

Ich gehe also davon aus, dass der richtige Weg ein wäre Transfer-Encoding: gzip(oder, wenn ich den Körper zusätzlich zerhacke, würde es werden Transfer-Encoding: gzip, chunked ). Und in diesem Fall kein Grund zum Berühren Varyoder für ETageinen anderen Header, da es sich um eine Sache auf Transportebene handelt.

Im Moment ist mir das "Hop-by-Hop" -Ness von Transfer-Encodingetwas nicht so wichtig , worüber sich andere in erster Linie Sorgen zu machen scheinen, da Proxys möglicherweise dekomprimiert und unkomprimiert an den Client weitergeleitet werden. Proxys können es jedoch genauso gut weiterleiten wie es ist (komprimiert), wenn die ursprüngliche Anforderung den richtigen Accept-EncodingHeader hat, was bei allen mir bekannten Browsern eine Selbstverständlichkeit ist.

Übrigens ist dieses Problem mindestens ein Jahrzehnt alt, siehe z . B. https://bugzilla.mozilla.org/show_bug.cgi?id=68517 .

Jede Klarstellung hierzu wird geschätzt. Sowohl in Bezug auf das, was als standardkonform angesehen wird, als auch in Bezug auf das, was als praktisch angesehen wird. Beispielsweise wären HTTP-Client-Bibliotheken, die nur transparente "Content-Encoding" unterstützen, ein Argument gegen die Praktikabilität.

Zitat von Roy T. Fielding , einem der Autoren von RFC 2616:

Eine inkonsistente Änderung der Inhaltscodierung im laufenden Betrieb (weder "nie" noch "immer") macht es unmöglich, dass spätere Anforderungen bezüglich dieses Inhalts (z. B. PUT oder bedingtes GET) korrekt behandelt werden. Dies ist natürlich der Grund für die Ausführung On-the-Fly-Inhaltscodierung ist eine blöde Idee, und warum ich HTTP Transfer-Encoding hinzugefügt habe, um die On-the-Fly-Codierung ohne Änderung der Ressource durchzuführen.

Quelle: https://issues.apache.org/bugzilla/show_bug.cgi?id=39727#c31

Mit anderen Worten: Do not do on-the-fly Content-Encoding, Verwendung Transfer-Encoding statt!

Bearbeiten: Das heißt, es sei denn, Sie möchten Clients, die nur die Inhaltscodierung verstehen, komprimierten Inhalt bereitstellen . Was leider die meisten von ihnen zu sein scheinen. Beachten Sie jedoch, dass Sie den Bereich der Spezifikation verlassen und möglicherweise auf Probleme wie das von Fielding und anderen erwähnte stoßen, z. B. wenn Caching-Proxys beteiligt sind.

Die korrekte Verwendung, wie in RFC 2616 definiert und tatsächlich in freier Wildbahn implementiert, besteht darin, dass der Client einen Accept-EncodingAnforderungsheader sendet (der Client kann mehrere Codierungen angeben). Der Server kann dann und nur dann die Antwort gemäß den vom Client unterstützten Codierungen codieren (wenn die Dateidaten nicht bereits in dieser Codierung gespeichert sind) und im Antwortheader angeben, Content-Encodingwelche Codierung verwendet wird. Der Client kann dann Daten basierend auf dem Transfer-Encoding(dh chunked) aus dem Socket lesen und sie dann basierend auf dem Content-Encoding(dh :) dekodieren gzip.

In Ihrem Fall würde der Client also einen Accept-Encoding: gzipAnforderungsheader senden , und dann könnte der Server entscheiden, (falls nicht bereits) zu komprimieren und einen Content-Encoding: gzipund optional einen Antwortheader zu senden Transfer-Encoding: chunked.

Und ja, der Transfer-EncodingHeader kann in Anforderungen verwendet werden, jedoch nur für HTTP 1.1, was erfordert, dass sowohl Client- als auch Server-Implementierungen die chunkedCodierung in beide Richtungen unterstützen.

ETagIdentifiziert die Ressourcendaten auf dem Server eindeutig, nicht die tatsächlich übertragenen Daten. Wenn eine bestimmte URL-Ressource ihren ETagWert ändert , bedeutet dies, dass sich die serverseitigen Daten für diese Ressource geändert haben.