Content-Encoding versus Transfer-Encoding: Repräsentationskodierungen und Nachrichten-Framing

Worum es geht

Content-Encoding listet die Kodierungen (gzip, br, zstd, deflate) auf, die über das hinaus, was der Medientyp bereits impliziert, auf eine Repräsentation angewendet werden; RFC 9110 beschreibt es so, dass Daten komprimiert werden können, ohne die Identität ihres zugrunde liegenden Medientyps zu verlieren. Die Repräsentation ist die kodierte Form: Content-Length, ETag und Byte-Bereiche beziehen sich allesamt auf die kodierten Bytes, die Kodierungen werden in der Reihenfolge ihrer Anwendung aufgelistet, und der Client handelt sie mit Accept-Encoding aus. Das Dekodieren geschieht normalerweise erst beim endgültigen Empfänger.

Transfer-Encoding (RFC 9112) listet Transfer-Kodierungen auf, die angewendet werden, um den HTTP/1.1-Nachrichtenkörper zu bilden, vor allem chunked, das Inhalte einrahmt, deren Länge beim Senden der Header noch unbekannt ist. RFC 9112 bezeichnet es als Eigenschaft der Nachricht, nicht der Repräsentation: Jeder Hop darf Kodierungen hinzufügen oder entfernen. chunked muss die letzte Kodierung sein und darf nicht zweimal angewendet werden; es ist in 1xx- und 204-Antworten verboten. Sind sowohl Transfer-Encoding als auch Content-Length vorhanden, gewinnt Transfer-Encoding, und RFC 9112 besagt, dass eine solche Nachricht auf Request Smuggling hindeuten kann und als Fehler behandelt werden sollte.

In HTTP/2 (RFC 9113) und HTTP/3 übernimmt das Protokoll das Framing; Transfer-Encoding ist ein verbindungsspezifisches Feld, das nicht vorkommen darf, und nur TE: trailers ist erlaubt.

Warum es wichtig ist

Beides zu vermischen erzeugt konkrete Fehler: Ein Proxy, der mit Content-Encoding im laufenden Betrieb komprimiert, aber den starken ETag des Ursprungs beibehält, bricht If-Range und bedingte Anfragen; eine Range-Anfrage gegen eine dynamisch komprimierte Antwort hat keine stabilen Offsets; eine von Hand gesetzte Content-Length neben chunked-Framing ist ein Vektor für Request Smuggling; ein HTTP/2-Client, der Transfer-Encoding: chunked sendet, wird als fehlerhaft abgelehnt.

So wird es angewendet

• Auf einer Schicht mit Content-Encoding komprimieren, den ETag je Kodierung unterschiedlich machen (oder schwache Validatoren verwenden), und Vary: Accept-Encoding senden.
• Vorkomprimierte Dateien als eigene Repräsentation mit korrekter Content-Length ausliefern; sie können gecacht und mit Range-Anfragen abgerufen werden.
• Den Server streamende HTTP/1.1-Antworten mit chunked einrahmen lassen; Content-Length für generierte Bodies nicht von Hand berechnen.
• In Proxys nie beide Felder weiterleiten; RFC 9112 verlangt, Content-Length zu entfernen und die Transfer-Kodierung zu verarbeiten.
• Daran denken, dass HEAD- und 304-Antworten Transfer-Encoding ohne Body tragen dürfen.

Stolpersteine

Content-Encoding: gzip bei einem .tar.gz-Download kann dazu führen, dass ein Browser die Datei dekomprimiert und ein reines Tarball unter dem Namen .gz speichert; RFC 9110 erwähnt, dass sich User Agents unterschiedlich verhalten, je nachdem, ob eine Kodierung in Content-Type oder Content-Encoding steht. Gemäss RFC 9112 ist chunked die einzige Transfer-Kodierung, die ein Server anwenden darf, sofern der Client in TE nicht andere aufgeführt hat. Ein Server darf Transfer-Encoding überhaupt nur senden, wenn die Anfrage HTTP/1.1 oder neuer war.