Transfer-Encoding
Verwendung
Der Header Transfer-Encoding ist ein Hop-by-Hop-Header, der beschreibt, wie der Nachrichten-Body für den aktuellen Verbindungsabschnitt kodiert ist. Jede Zwischenstation (Proxy, Gateway) dekodiert die Transfer-Kodierung, verarbeitet die Nachricht und kodiert sie erneut, bevor sie an den nächsten Knoten weitergeleitet wird.
Der häufigste Wert ist chunked. Er erlaubt es einem Server, mit dem Streaming einer Antwort zu beginnen, bevor die gesamte Content-Length bekannt ist. Der Server zerlegt den Body in Chunks, denen jeweils eine Größenangabe vorangestellt ist. Ein Chunk der Länge null signalisiert das Ende der Nachricht.
Anders als Content-Encoding, das eine Ende-zu-Ende-Komprimierung auf die Ressource selbst anwendet, wirkt Transfer-Encoding nur zwischen zwei benachbarten Knoten. Ein Server, der eine gzip-komprimierte Ressource über eine chunked-Verbindung sendet, nutzt Content-Encoding für die Komprimierung und Transfer-Encoding für die Zerlegung in Chunks.
Erscheint Transfer-Encoding in einer Antwort auf eine HTTP-HEAD-Anfrage, gibt der Wert die Kodierung wieder, die der Server in einer entsprechenden GET-Antwort auf den Body anwenden würde.
Hinweis
Content-Encoding wirkt Ende-zu-Ende: Die Ressource selbst wird komprimiert (z. B. gzip) und jeder Empfänger dekodiert die Nutzlast. Transfer-Encoding wirkt Hop-by-Hop: Die Kodierung wird für den Transport zwischen zwei benachbarten Knoten angewendet und bei jedem Hop wieder entfernt. Eine Antwort kann beide Header gleichzeitig führen und dabei Content-Encoding für die Ressourcenkomprimierung und Transfer-Encoding für die chunked-Auslieferung verwenden.
Hinweis
Der HTTP-Header Transfer-Encoding hat nichts mit dem Content-Transfer-Encoding aus der E-Mail-Welt zu tun, das die MIME-Kodierung wie base64 oder quoted-printable für E-Mail-Bodys regelt.
Hinweis
Der Header Transfer-Encoding ist in HTTP/2 und HTTP/3 verboten. Diese Protokolle bringen eigene Mechanismen zum Daten-Framing mit, wodurch eine Kodierung auf Transportebene überflüssig wird.
chunked
Die Direktive chunked teilt den Nachrichten-Body in eine Folge von Chunks auf. Jeder Chunk beginnt mit der Chunk-Größe in hexadezimaler Schreibweise, gefolgt von den Chunk-Daten. Ein abschließender Chunk der Größe null beendet die Nachricht. Der Header Trailer listet alle Felder auf, die nach dem letzten Chunk angehängt werden.
compress
Die Direktive compress wendet die Lempel-Ziv-Welch-Komprimierung (LZW) an. Diese Kodierung wird in modernen Umgebungen nur selten eingesetzt.
deflate
Die Direktive deflate wendet die zlib-Komprimierung mit dem deflate-Algorithmus an.
gzip
Die Direktive gzip wendet die Lempel-Ziv-Kodierung (LZ77) mit einer 32-Bit-CRC-Prüfsumme an. Es handelt sich um denselben Algorithmus, den das gzip-Dateiformat verwendet; er wird von HTTP-Implementierungen breit unterstützt.
Beispiel
Ein Server sendet eine chunked-Antwort. Das Fehlen eines Content-Length-Headers zeigt an, dass der Server den Body stückweise streamt.
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
7\r\n
Mozilla\r\n
9\r\n
Developer\r\n
0\r\n
\r\nMehrere Transfer-Kodierungen werden der Reihe nach angewendet. In dieser Antwort wird der Body zunächst gzip-komprimiert und anschließend für die Übertragung in Chunks zerlegt.
Transfer-Encoding: gzip, chunked