[504] 転送符号化transfer codingは、 ネットワーク上の「安全な輸送路safe transport」 を確保するために payload body に適用される、 されることがある、あるいは必要であるかもしれない符号化変形encoding transformationです >>502。

[505] HTTP には転送符号化の他に内容符号化がありますが、 内容符号化が表現の特性であるのに対し、転送符号化はメッセージの特性です >>502。[3] HTTP/2 では転送符号化を使いません。

仕様書

転送符号化の指定

[510] 転送符号化は、名前で識別します。名前に加えて零個以上の引数を指定することができます。 >>502

[511] この指定は、 Transfer-Encoding: ヘッダーや、 TE: ヘッダーで使われます。

[512] 名前は、字句です。大文字・小文字不区別です。 IANA登録簿に登録するべきought toです。 >>502

[515] 引数の前には、 ; が必要です >>502。 ; の前後には、 OWS を挿入できます >>502。

[513] 引数は、名前か名前と値の組とされています >>502 が、構文上値は必須となっています。名前と値の間には = が必要です >>502。名前は字句、 値は字句または引用文字列です >>502。

[514] = の前後には BWS を挿入できます >>502。

[516] 引数の順序や重複、大文字と小文字、未対応の場合の対処などは言及がありません。 また HTTP 本体仕様および関連仕様や、実際の用例で、引数を用いた例はありません。

[519] TE: ヘッダーには特別な q 引数を指定することができますが、定義上は転送符号化の引数とはされていません。 また、他の引数より後に置かなければならない構文となっています。 q 引数では BWS や引用文字列は認められていません。
  1. 字句
  2. *
    1. OWS
    2. ;
    3. OWS
    4. 字句
    5. =
    6. |
      1. 字句
      2. 引用文字列

転送符号化名の一覧

[517] 転送符号化の名前には、次のものがあります。

[518] chunked は特別な転送符号化で、 HTTP/1.1 で実装が義務付けられている他、他の転送符号化とは異なる要件が色々あります。 HTTP/2 では利用が禁止されています。

[506] trailers は転送符号化ではなく、 chunked のオプションのようなものですが、 TE: ヘッダーでは転送符号化と共に指定できます。 (Transfer-Encoding: ヘッダーには指定できません。)

[528] IANAREG にはありません。

[507] identity は RFC 2616 にありましたが、 その正誤表で削除されています。

[529] 内容符号化と一部名前が共通していますが、 内容符号化と転送符号化は別のものとされていますから、 片方で使えるからといって他方でも使えるとは限りません。

[4] chunked 以外の転送符号化は、現在では実装されていません。 chunked と trailers 以外の値は、 相互運用性のため、使うべきではありません。

[533] 転送符号化の名前の一覧が >>532 に JSON 形式で含まれています。

IANA 登録簿

[508] 転送符号化の名前は IANA登録簿 >>523 があります >>524。

[509] 元は根拠不詳であり、登録手続きは

Registration Procedures: First Come First Served with specification recommended

(先来先給、仕様書推奨) とされていました。

[525] その後 RFC 7230 が定義するようになり、登録手続きは IETF Review に変更されています。

[526] 内容符号化と同じ名前は、同じ符号化でないと使ってはいけないことになっています >>524, >>1。

処理

[521] 串は、転送符号化を適用したり、除去したりしてから転送して構いません >>520。

[522] 特に HTTP/1.1 から HTTP/1.0 へと転送する時には、 すべての転送符号化を除去することになります。

[6] TE: や Transfer-Encoding: や chunked やメッセージ本体も参照。

要求での利用

[8] 仕様上は要求でも転送符号化を使えることになっていますが、 実際には使われることはありません。

[9] 要求では TE: ヘッダーに相当するもので折衝することもできません。

セキュリティー

[2] 圧縮を用いると、 BREACH 攻撃に使われる危険性があります。 内容符号化とは違って転送符号化は送信者が完全に制御することはできませんから、 特に注意が必要かもしれません。実装は圧縮を使わないべきかもしれません。 利用者や著者は圧縮を使う可能性があるプロキシに接続しないよう注意するべきかもしれません。

内容符号化のセキュリティーの項も参照。

[5] 一般的な利用者エージェントは TE: ヘッダーを指定しないので、普通のサーバーは chunked 以外の転送符号化を使いませんから、問題にはならなそうです。

歴史

[503] RFC 2068・2616 (HTTP/1.1) 3.6 Transfer Codings

Transfer-coding values are used to indicate an encoding transformation that has been, can be, or may need to be applied to an entity-body in order to ensure "safe transport" through the network. This differs from a content coding in that the transfer-coding is a property of the message, not of the original entity.

transfer-coding 値は、ネットワークを通した「安全な輸送」 を確保するために entity-body に適用している、 適用することができる、あるいは適用する必要がある符号化変形を示すのに使います。 転送符号化はメッセージの特性であってもとの実体の特性ではないという点において、 転送符号化は内容符号化と異なります。

  • transfer-coding = "chunked" | transfer-extension
  • transfer-extension = token *( ";" parameter )

Parameters are in the form of attribute/value pairs.

引数は属性・値の組の形です。

  • parameter = attribute "=" value
  • attribute = token
  • value = token | quoted-string

All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in the TE header field (section 14.39) and in the Transfer-Encoding header field (section 14.40 14.41).

すべての transfer-coding 値は大文字・小文字を区別しません。 HTTP/1.1 は TE 頭欄と Transfer-Encoding 頭欄で transfer-coding 値を使います。

Whenever a transfer-coding is applied to a message-body, the set of transfer-codings MUST include "chunked", unless the message is terminated by closing the connection. When the "chunked" transfer-coding is used, it MUST be the last transfer-coding applied to the message-body. The "chunked" transfer-coding MUST NOT be applied more than once to a message-body. These rules allow the recipient to determine the transfer-length of the message (section 4.4).

message-body が transfer-coding に適用する時は常に、 transfer-coding の集合はメッセージを接続を閉じることによって終端する場合を除き、 chunked を含まなければなりません。 chunked を使うときは、 message-body に適用する最後の transfer-coding でなければなりません。 chunked transfer-coding は、一つの message-body に複数回適用してはなりません。 これらの規則は受信者がメッセージの transfer-length を決定することを可能とします。

Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME [7] , which were designed to enable safe transport of binary data over a 7-bit transport service. However, safe transport has a different focus for an 8bit-clean transfer protocol. In HTTP, the only unsafe characteristic of message-bodies is the difficulty in determining the exact body length (section 7.2.2), or the desire to encrypt data over a shared transport.

transfer-coding は 7ビット輸送サービス上でバイナリ・データを安全に輸送することを可能とするために設計された MIME の Content-Transfer-Encoding に相当するものです。 しかし、安全な輸送は8ビット安全転送プロトコルでは違った焦点があります。 HTTP では、 message-body の唯一の非安全な性質は正確な本体の長さを決定することの困難性や共有輸送路上でデータを暗号化したいという希望です。

The Internet Assigned Numbers Authority (IANA) acts as a registry for transfer-coding value tokens. Initially, the registry contains the following tokens: "chunked" (section 3.6.1), {2616; Errata で削除} "identity" (section 3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and "deflate" (section 3.5).

IANA が transfer-coding 値字句の登録簿として機能します。 最初に、登録簿は次の字句を含みます : chunked, identity, gzip, compress, deflate。

New transfer-coding value tokens SHOULD be registered in the same way as new content-coding value tokens (section 3.5).

新しい transfer-coding 値字句は新しい content-coding 値字句と同じ方法で登録するべきです。

A server which receives an entity-body with a transfer-coding it does not understand SHOULD return 501 (Unimplemented), and close the connection. A server MUST NOT send transfer-codings to an HTTP/1.0 client.

理解しない transfer-coding の entity-body を受信したサーバーは、 501 (mijissou) を返し、接続を閉じるべきです。サーバーは HTTP/1.0 クライアントに transfer-coding を送ってはなりません。

3.6.1 Chunked Transfer Coding

→chunked

実装

[531] 転送符号化の名前の大文字と小文字を区別する実装もありました >>530。