[33] Transfer-Encoding: ヘッダーは、
当該メッセージに含まれるメッセージ本体に適用される(されている)転送符号化を表すものです。
[15] HTTP/1.1 の chunked 符号化を使うことを示すために使われます。
HTTP/1.0 や HTTP/2 では使いません。
[31] 要求メッセージは通常メッセージ本体を持ちませんが、
Transfer-Encoding: が指定されていればメッセージ本体を持ちます
>>30。
[45] HEAD 要求に対する応答や、
304 応答は、メッセージ本体を持たないことになっていますが、
Transfer-Encoding: 欄は指定しても構いません。
その場合、無条件GETであったなら起源鯖が適用するであろう転送符号化を表します。
>>34
[35] 欄値は、1つ以上の転送符号化のリスト (#) です >>34。
[42] これはメッセージ本体に適用されている転送符号化を表します。 複数指定されている場合は、元々のデータが前の転送符号化から順に符号化されていることを表します。 元のデータを取り出すためには、メッセージ本体に対して後の転送符号化から順に復号していけば良いことになります。
[306] 1xx 応答、204 応答、
CONNECT メソッドに対する 2xx
応答は、メッセージ本体を持たないことになっており、
鯖は
Transfer-Encoding: 欄を指定してはなりません。 >>34
[313] CONNECT メソッドに対する 2xx
応答は、メッセージ本体を持たないことになっており、
鯖は
Transfer-Encoding: 欄を指定してはなりません >>34, >>316。
クライアントは指定されていても無視しなければなりません >>30 3.3.3., >>316。
[308] クライアントは、鯖が HTTP/1.1 (以降) に対応していると分かっている場合を除き、
Transfer-Encoding: ヘッダーを使った要求を送信してはなりません。
>>34
Transfer-Encoding:
を使えないということになります。前回の応答で HTTP/1.1 が使われていたと覚えておけば、
使うことができますが...[309] 鯖は、要求のプロトコルの版が HTTP/1.1 (以降) の場合を除き、
Transfer-Encoding: ヘッダーを使った応答を送信してはなりません。
>>34
[312] Content-Length: ヘッダーと併用することはできません >>30。
両方がある時は、 Transfer-Encoding:
が優先されます >>30 3.3.3.。送信者は転送前に Content-Length:
を削除しなければなりません >>30 3.3.3.。
[3] RFC 723x には Transfer-Encoding を
Connection: ヘッダーに指定しなければならないとの規定はなく、
実際にも指定するのは一般的では無いようです。意味的には、
指定するべきようにも思われます。 RFC 7540 は Transfer-Encoding:
ヘッダーは connection-specific header であると述べており >>1、
暗に Connection: に示されるべきとの見解を示しています。
[44] 串や関門は、メッセージ本体の転送符号化を復号して
Transfer-Encoding: から削除したり、
転送符号化を適用して Transfer-Encoding:
に追加したりしても構いません >>34, >>315。
[317] HTTP/1.0 メッセージに Transfer-Encoding:
が使われている場合について特に言及はなく、 HTTP/1.1 の場合と変わらず処理するべきと思われます。
[2] HTTP/1.0/HTTP/1.1 から HTTP/2 に変換する中間器は、
Connection: に Transfer-Encoding
が明示されているか否かに関わらず、 Transfer-Encoding:
ヘッダーがあれば削除するべきです >>1。
[8] Chrome も Firefox も IE も、未対応の転送符号化だけが指定されていると、 無視するようです。
[9] Chrome と Firefox は、 chunked が指定されていると、
それ以外が前後どちらに指定されていても、 chunked として処理するようです。
chunked が複数指定されていても一度の指定とみなすようです。
[13] IE は chunked と未対応の転送符号化の両方が指定されていると、
無視する (転送符号化なしとみなす) ようです。
[14] Chrome や Firefox や IE は、 Transfer-Encoding: chunked
があれば、 Content-Length: は無視されます。
Content-Length: のエラーチェックもされないようです。
[38] 転送符号化の種類とその名前については、転送符号化を参照してください。
[39] chunked は特別な転送符号化です。 HTTP/1.1
では実装が義務付けられていますし、他とは異なる要件も課されています。
chunked の項を参照してください。[311] chunked 転送符号化以外の転送符号化を用いるときは、
最終的に chunked 転送符号化も適用するか、
または接続を閉じることによってメッセージを終端させるかのいずれかとしなければなりません
>>34。
The Transfer-Encoding general-header field indicates what (if any) type of transformation has been applied to the message body in order to safely transfer it between the sender and the recipient. This differs from the
Content-Encodingcontent-coding in that the transfer-coding is a property of the message, not of the entity.
Transfer-Encoding 一般頭欄は、
メッセージ本体を送信者と受信者の間で安全に転送するために変形が適用されているなら、どの型の変形が適用されているのかを示します。
transfer-coding はメッセージの特性であって実体の特性ではないという点で
content-coding とは異なります。
- Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding
Transfer-codings are defined in section 3.6. An example is:
- Transfer-Encoding: chunked
If multiple encodings have been applied to an entity, the transfer-codings MUST be listed in the order in which they were applied. Additional information about the encoding parameters MAY be provided by other entity-header fields not defined by this specification.
一つの実体に複数の符号化が適用されているのなら、
transfer-coding は適用された順に列挙しなければなりません。
符号化引数についての追加の情報をこの仕様書で定義しない他の実体頭欄で提供しても構いません。
Many older HTTP/1.0 applications do not understand the Transfer-Encoding header.
多くの古い HTTP/1.0 応用は、 Transfer-Encoding 頭を理解しません。
[26] Opera 6.05 (Win32) は TE: deflate, gzip, chunked, identity, trailers を送ってきます。実際ちゃんと対応しています。 Transfer-Encoding: x-gzip みたいな値でも解釈してくれます。
[27] >>26 複数の値を指定しても OK です。 gzip,deflate とか gzip,chunked みたいに。chunked,gzip (不正) も解してくれますが、 chunked,gzip,chunked(不正)や chunked,chunked だと内側の chunked が解されずに残ります。
[28] 手元の WinIE 3.02, NC 4.01, w3m 0.3.2.2 はいずれも転送符号化に対応していません。
[37] Transfer-Encoding: は Content-Transfer-Encoding:
と似ていますが、 CTE が8ビット安全でない輸送路に任意のデータを通すためのものなので、
元々8ビット安全である HTTP の Transfer-Encoding:
とは目的が違っています >>34。
[40] Transfer-Encoding: はメッセージの特性であり、
Content-Encoding: は表現の特性であるとされています。 >>34
転送符号化は中間器が適宜復号したり、符号化したりして構わないことになっていますが、
内容符号化は中間器が変更してはなりません。
[21] HTTP には転送符号化と内容符号化という似た二つの概念があります。
前者は転送を安全に行うための手段であって chunked 符号化が現在実質的に唯一使えます。 Transfer-Encoding: 欄の他に TE 欄が関係します。
後者はその名の通り内容の符号化ですが、現時点では実質的に圧縮転送のための手段となっています。
[22] HTTP から派生したプロトコルである RTSP や SIP では chunked 符号化を禁止するなど差異がありますので注意が必要です。
[23] CGI で転送符号化した内容を出力するのって機能するんでしょうか? 仕様書には特に触れられていませんね。
サーバーが Apache でクライアントが HTTP/1.1 の場合は、 CGI や SSI などを使うと chunked 符号化をサーバー側が処理するみたいですが・・・。
Transfer-Encoding: gzip
Connection: close
I tested this response with five major browsers. All of them seem to know
to consume the response body till connection EOF. ( None of them knows how
to deal with the 'gzip' encoding; and if EOF arrives prematurely resulting
in a corrupted 'gzip' body, none of them detects it as a problem. )
[10] Issue 94730 - chromium - RFC2616 "Transfer-Encoding: gzip, chunked" not handled properly - An open-source project to help move the web forward. - Google Project Hosting ( 版) <https://code.google.com/p/chromium/issues/detail?id=94730>
[11] 68517 – RFE: Improved support for HTTP/1.1 transfer codings (transfer-encoding) ( 版) <https://bugzilla.mozilla.org/show_bug.cgi?id=68517>
[12] 59464 – Any Transfer-Encoding header is interpreted as "chunked" ( 版) <https://bugzilla.mozilla.org/show_bug.cgi?id=59464>
chunked以外の転送符号化を指定することもできますが、 実際には使われません。