Transfer-Encoding
Der Transfer-Encoding
-Header gibt die Form der Kodierung an, die zum Übertragen von Nachrichten zwischen Knoten im Netzwerk verwendet wird.
Warnung: HTTP/2 verbietet alle Verwendungen des Transfer-Encoding-Headers außer dem HTTP/2-spezifischen: "trailers"
.
HTTP/2 und spätere Versionen bieten effizientere Mechanismen für das Daten-Streaming als Chunked Transfer und verbieten die Verwendung des Headers.
Die Verwendung des Headers in HTTP/2 kann wahrscheinlich zu einem spezifischen protocol error
führen, da das HTTP/2-Protokoll die Verwendung verbietet.
Transfer-Encoding
ist ein hop-by-hop header, der auf eine Nachricht zwischen zwei Knoten angewendet wird, nicht auf eine Ressource selbst.
Jedes Segment einer Multi-Knoten-Verbindung kann unterschiedliche Transfer-Encoding
-Werte verwenden.
Wenn Sie Daten über die gesamte Verbindung komprimieren möchten, verwenden Sie stattdessen den end-to-end Content-Encoding
-Header.
Wenn er in der Antwort auf eine HEAD
-Anfrage vorhanden ist, die keinen Body hat, gibt er den Wert an, der auf die entsprechende GET
-Nachricht angewendet worden wäre.
Header-Typ | Request header, Response header, Content header |
---|---|
Verbotener Header-Name | ja |
Syntax
Transfer-Encoding: chunked
Transfer-Encoding: compress
Transfer-Encoding: deflate
Transfer-Encoding: gzip
// Several values can be listed, separated by a comma
Transfer-Encoding: gzip, chunked
Direktiven
chunked
-
Daten werden in einer Reihe von Blöcken gesendet. Der
Content-Length
-Header wird in diesem Fall weggelassen und am Anfang jedes Blocks muss die Länge des aktuellen Blocks in hexadezimalem Format hinzugefügt werden, gefolgt von\r\n
und dann dem Block selbst, gefolgt von einem weiteren\r\n
. Der abschließende Block ist ein regulärer Block, mit der Ausnahme, dass seine Länge null ist. Er wird vom Trailer gefolgt, der aus einer (möglicherweise leeren) Sequenz von Header-Feldern besteht. compress
-
Ein Format unter Verwendung des Lempel-Ziv-Welch (LZW)-Algorithmus. Der Wertename wurde vom UNIX-Programm compress übernommen, das diesen Algorithmus implementierte. Wie das Compress-Programm, das von den meisten UNIX-Distributionen verschwunden ist, wird diese Content-Encoding heutzutage von fast keinem Browser mehr verwendet, teilweise aufgrund eines Patentproblems (das 2003 ablief).
deflate
-
Verwendung der zlib-Struktur (definiert in RFC 1950), mit dem deflate-Kompessionsalgorithmus (definiert in RFC 1951).
gzip
-
Ein Format unter Verwendung der Lempel-Ziv-Kodierung (LZ77), mit einem 32-Bit-CRC. Dies ist ursprünglich das Format des UNIX-Programms gzip. Der HTTP/1.1-Standard empfiehlt auch, dass die Server, die dieses Content-Encoding unterstützen,
x-gzip
als Alias erkennen sollten, aus Kompatibilitätsgründen.
Beispiele
Chunked Encoding
Chunked Encoding ist nützlich, wenn größere Datenmengen an den Client gesendet werden und die Gesamtgröße der Antwort möglicherweise nicht bekannt ist, bis die Anfrage vollständig verarbeitet wurde. Zum Beispiel beim Generieren einer großen HTML-Tabelle, die aus einer Datenbankabfrage resultiert, oder beim Übertragen großer Bilder. Eine Chunked-Antwort sieht folgendermaßen aus:
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
7\r\n
Mozilla\r\n
11\r\n
Developer Network\r\n
0\r\n
\r\n
Spezifikationen
Specification |
---|
HTTP/1.1 # field.transfer-encoding |
Browser-Kompatibilität
BCD tables only load in the browser
Siehe auch
Accept-Encoding
Content-Encoding
Content-Length
- Header-Felder, die die Verwendung von Trails regeln:
TE
(Anfragen) undTrailer
(Antworten). - Chunked Transfer Encoding