[88] Connection: ヘッダーは、 現在のHTTP接続に関する制御オプションを指定するものです >>87。

仕様書

構文

[92] 欄値は、1つ以上の接続オプションのリスト (#) です。 接続オプションは、字句で、大文字・小文字不区別です。 >>87

  1. 字句
  2. *
    1. OWS
    2. ,
    3. OWS
    4. 字句

文脈

[84] このヘッダーは HTTP/1.1 仕様書で規定されていますが、すべての HTTP/1.x に対して定義されています >>83。 HTTP/1.1 に適合するかに関わらず、すべての HTTP/1.x の実装はこのヘッダーを実装するべきです >>83。

[22] HTTP/2 では使用しません。エンドポイントは connection-specific header field を生成してはなりません。 >>21

[90] 送信者は、 Connection: 以外のヘッダーを使って現在の接続についてのオプションを指定するときは、 そのヘッダー名を Connection: ヘッダーに含めなければなりません >>87。

[91] このヘッダーは複数指定できます。

処理

[86] 串や関門は、Connection: を実装しなければなりません >>85。

[89] 串や関門は、メッセージを転送する前に、 Connection: に名前が指定されているヘッダーと Connection: ヘッダーを削除するか、 メッセージを転送する接続のオプションを示すものに置換するかしなければなりません >>87。

[13] 持続接続も参照。

[23] HTTP/2 エンドポイントは、 TE: 以外の connection-specific header field を含むメッセージを奇形としなければなりません >>21。

[32] 実際には Chrome や Firefox では Content-Length: と Transfer-Encoding: 以外は奇形とみなされないようです。 これらについては各項を参照。

[24] HTTP/1.0/HTTP/1.1 から HTTP/2 へ変換する中間器は、 Connection: ヘッダーとそこで示されたヘッダーを削除する必要があります >>21。 更に Keep-Alive:, Proxy-Connection:, Transfer-Encoding:, Upgrade: その他の connection-specific header field は、 Connection: に明示されていなくても削除するべきです。 >>21

[25] TE: trailers は残し、それ以外の値は削除するべきようにも思えますが、 明記されていません。

[30] 複数のヘッダーで、またはリストの項目として close が指定されていれば、 Firefox は接続を閉じます。 Chrome や IE は、 close が keep-alive より先に指定されていれば、接続を閉じます。

[31] Connection: close も参照。

[33] nginx も Apache も、指定順序に関わらず keep-alive より close を優先します。

[34] Apache は , (前後に任意個の空白) で区切った時 keep-alive や close が ASCII大文字・小文字不区別で含まれるかどうかを調べます。 nginx は部分一致で keep-alive や close が ASCII大文字・小文字不区別で含まれるかどうかを調べます。

[35] nginx は、接続HTTP接続を閉じない場合には、 Connection: keep-alive を送信します。

[36] Apache は、 HTTP/1.1 で接続HTTP接続を閉じない応答では、 Connection: を特に送信しません。 HTTP/1.0 で要求に Connection: keep-alive が指定されていれば、応答に Connection: Keep-Alive と Keep-Alive: ヘッダーを含めます。

[37] ChromeDriver は、要求に Connection: close があっても、 無視します。応答に Connection: close を指定しますが、 自身のその指定も意味がなく、接続HTTP接続は閉じられません。 その状態で次の要求を送信すると、また Connection: close の応答が送られてきますが、やはり閉じられません。

接続オプション

[96] Connection: ヘッダーのリストの値である接続オプションは、 ヘッダー名と名前空間を共有しています。値を指定することで、 当該接続についてのオプションを指定することとなり、 同名のヘッダーがあればそれに関する更なるオプションとして扱われます。

[15] Connection: keep-alive は単独でも指定できますが、更に Keep-Alive: ヘッダーにオプションを指定することもできます。

[99] 接続オプションは、特に引数がない場合には、 Connection: ヘッダーにだけ現れて実際のヘッダーが存在しないこともあります >>87。

[16] Connection: close に対応するヘッダーは用意されていません。

[17] Connection: meter は Meter: ヘッダーが特に指定されていない場合、 Meter: (値は空文字列。) が指定されたのと同じ意味と定義されています。

[100] 接続オプションが Connection: ヘッダーに現れずに対応するヘッダーだけがある場合、 そのヘッダーは誤って転送されてきたものかもしれず、 受信者が無視するべきought toです >>87。

[101] 新しい接続オプションを定義しようとする仕様書の著者は、 既存のヘッダー名を調査して、衝突しないように注意するべきought toです。 新しい接続オプションを定義すると、それと同じヘッダー名を別の目的に使うのはよくありませんから、 実質的にヘッダー名を予約することとなります。 >>87

[26] RFC 7230 は接続オプションと同名のヘッダーのことを表す用語を明示的に定義はしていませんが、 connection-specific header field という語を2回使っています。 RFC 7540 はこの語を採用しています。

[93] 送信者は、payload の受信者すべてに向けたヘッダーを Connection: に指定してはなりません >>87。

[94] 例えば Cache-Control: は不適切です >>87。

[95] すべてのリストがほしいところですね。

[9] RFC 7231 はヘッダーの仕様書に対し、 Connection: ヘッダーに指定するのが適当かどうか明記することを検討するよう求めています >>8。

[97] 次のような値が接続オプションや connection-specific header field として使われています。

[19] close 以外は対応するヘッダーがあります。 keep-alive と Meter はヘッダーもありますが、ヘッダー無しでも使えます。

[20] >>97 に挙げたものの他、 C-Man: や C-Opt: で宣言されたヘッダー接頭辞を使ったヘッダーも Connection: に指定しなければなりません。

拡張宣言を参照。

[4] Upgrade: や TE: や Meter: >>14 は、使用する場合必ず Connection: に指定しなければならないと規定されています。

[103] Content-Length や Transfer-Encoding や Trailer は、接続オプションとして使われることはないようです。 (串が書き換えることもできますが、基本的にはそのまま転送して良いものだからでしょう。) ただし RFC 7540 は Transfer-Encoding も connection-specific header field だと述べています >>21。[10] Proxy-Authenticate: や Proxy-Authorization: は接続オプションとして使われるわけでは無いようです。

[12] Prefer: は、 Connection: に指定して当該接続のみに適用させられることが仕様書で敢えて言及されています >>11。

[18] Prefer: は通常は起源鯖に対して指定するので Connection: には指定しません。 (当該接続にのみ適用したいことが本当にあるのか謎ですが。。。)[38] クライアントが Prefer: を指定して、途中のプロキシが更に Prefer: を指定したいとき、両者を区別する方法がないので、 Prefer: をプロキシ用に転用することの有用性は謎です。

[27] Proxy-Connection: は RFC 7540 で connection-specific header field に分類されています >>21。 接続オプションとして使われることはないかもしれません。

[39] Host: は特に connection-specific header field に分類されているわけではありませんが、 HTTP/1 で転送するときは適切に付加し、 HTTP/2 で転送するときは除去する必要があり、同種のものと捉えられます。

[43] Connection: 自体も、特に connection-specific header field に分類されているわけではありませんが、転送時はその値に従い既存のヘッダーを削除してから、 本ヘッダーも削除または適切な値に置き換える必要があります。

[7] 接続オプションとして使われる値の一覧の JSON データがあります。

  • [40] data-web-defs/headers.json at master · manakai/data-web-defs () https://github.com/manakai/data-web-defs/blob/master/data/headers.json
    • [6] data-web-defs/headers.txt at master · manakai/data-web-defs ( 版) https://github.com/manakai/data-web-defs/blob/master/doc/headers.txt

[41] 接続オプションの一覧を取得するには:

$ curl -fL https://raw.githubusercontent.com/manakai/data-web-defs/master/data/headers.json | ./jq '.headers | map(select(.http.connection_option)) | map (.name)'

[42] プロキシが削除するべきヘッダー名の一覧を取得するには:

$ curl -fL https://raw.githubusercontent.com/manakai/data-web-defs/master/data/headers.json | ./jq '.headers | map(select(.http.proxy_removed)) | map (.name)'

セキュリティー

[28] Connection: ヘッダーの値は、 fingerprinting vector かもしれません。

歴史

[98] RFC 2068・2616 (HTTP/1.1) 14.10 Connection

The Connection general-header field allows the sender to specify options that are desired for that particular connection and MUST NOT be communicated by proxies over further connections.

Connection 一般頭欄によって、 送信者がその特定の接続における望まれる選択子を指定することが出来ます。 この頭欄は、串により更なる接続において通信してはなりません。

The Connection header has the following grammar:

Connection 頭は次の文法を持ちます :

  • Connection = "Connection" ":" 1#(connection-token)
  • connection-token = token

HTTP/1.1 proxies MUST parse the Connection header field before a message is forwarded and, for each connection-token in this field, remove any header field(s) from the message with the same name as the connection-token. Connection options are signaled by the presence of a connection-token in the Connection header field, not by any corresponding additional header field(s), since the additional header field may not be sent if there are no parameters associated with that connection option.

HTTP/1.1 串は、メッセージが転送される前に Connection 頭欄を解析しなければならず、 この欄中の各 connection-token について、 connection-token と同じ名前の全ての頭欄をメッセージから削除します。 接続選択子は、 Connection 頭欄中の connection-token の出現により通知されます。 それに対応する追加の頭欄によってではありません。 その接続選択子に関連付けられた引数がないときに追加の頭欄は送信されないかもしれないからです。

Message headers listed in the Connection header MUST NOT include end-to-end headers, such as Cache-Control.

Connection 頭に列挙されたメッセージ頭並びは、 Cache-Control などの末端対末端頭を含んではなりません。

HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion of the response. For example,

HTTP.1,1 は、その応答の完了後に接続を閉じることを送信者が通知する close 接続選択子を定義します。例えば、 要求頭欄並び中であれ応答頭欄並び中であれ、

  • Connection: close

in either the request or the response header fields indicates that the connection should not SHOULD NOT be considered `persistent' (section 8.1) after the current request/response is complete.

は現在の要求・応答が完了した後に接続が「永続」 とみなされるべきではないことを示します。

HTTP/1.1 applications that do not support persistent connections MUST include the "close" connection option in every message.

永続接続に対応していない HTTP/1.1 応用は各メッセージ中に close 接続選択子を含めなければなりません。

A system receiving an HTTP/1.0 (or lower-version) message that includes a Connection header MUST, for each connection-token in this field, remove and ignore any header field(s) from the message with the same name as the connection-token. This protects against mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. See section 19.6.2.

Connection 頭を含んだ HTTP/1.0 (又はそれ以下の版) のメッセージを受信したシステムは、 この欄中の各 connection-token について、メッセージ中の connection-token と同じ名前の全ての頭欄を削除・無視しなければなりません。 これによってそれらの頭欄が HTTP/1.1 以前の串によって誤って転送されることを防ぎます。

関連

[102] 接続、持続的接続の項も参照してください。

[1] 串に関係して使われる同種の頭欄には、

が見つかっています。

[2] HTTP-Connection, Nncoection も同類っぽ。

[3] Proxy----------- もそうかも。

[104] RFC 3507 - Internet Content Adaptation Protocol (ICAP) ( ( 版)) http://tools.ietf.org/html/rfc3507#section-4.3.1

[105] RFC 2660 - The Secure HyperText Transfer Protocol ( ( 版)) http://tools.ietf.org/html/rfc2660#section-2.6.3.3

[29] ( 版) http://storage.sakura.ad.jp/pdf/base_storage_api_reference.pdf

Connection サーバへの接続が開いているか閉じているかの状態となります

型:列挙型 (open / close)