[88] Connection:
ヘッダーは、
現在のHTTP接続に関する制御オプションを指定するものです >>87。
[92] 欄値は、1つ以上の接続オプションのリスト (#
) です。
接続オプションは、字句で、大文字・小文字不区別です。 >>87
[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。
[86] 串や関門は、Connection:
を実装しなければなりません >>85。
[89] 串や関門は、メッセージを転送する前に、
Connection:
に名前が指定されているヘッダーと
Connection:
ヘッダーを削除するか、
メッセージを転送する接続のオプションを示すものに置換するかしなければなりません >>87。
[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
[30] 複数のヘッダーで、またはリストの項目として close
が指定されていれば、 Firefox は接続を閉じます。
Chrome や IE は、 close
が keep-alive
より先に指定されていれば、接続を閉じます。
Connection: close
も参照。[33] nginx も Apache も、指定順序に関わらず keep-alive
より close
を優先します。
[34] Apache は ,
(前後に任意個の空白) で区切った時
keep-alive
や close
が ASCII大文字・小文字不区別で含まれるかどうかを調べます。
nginx は部分一致で keep-alive
や close
が
ASCII大文字・小文字不区別で含まれるかどうかを調べます。
[35] nginx は、接続を閉じない場合には、
Connection: keep-alive
を送信します。
[36] Apache は、 HTTP/1.1 で接続を閉じない応答では、
Connection:
を特に送信しません。
HTTP/1.0 で要求に Connection: keep-alive
が指定されていれば、応答に Connection: Keep-Alive
と Keep-Alive:
ヘッダーを含めます。
[37] ChromeDriver は、要求に Connection: close
があっても、
無視します。応答に Connection: close
を指定しますが、
自身のその指定も意味がなく、接続は閉じられません。
その状態で次の要求を送信すると、また Connection: close
の応答が送られてきますが、やはり閉じられません。
[96] Connection:
ヘッダーのリストの値である接続オプションは、
ヘッダー名と名前空間を共有しています。値を指定することで、
当該接続についてのオプションを指定することとなり、
同名のヘッダーがあればそれに関する更なるオプションとして扱われます。
[15] Connection: keep-alive
は単独でも指定できますが、更に
Keep-Alive:
ヘッダーにオプションを指定することもできます。
[99] 接続オプションは、特に引数がない場合には、 Connection:
ヘッダーにだけ現れて実際のヘッダーが存在しないこともあります >>87。
[16] Connection: close
に対応するヘッダーは用意されていません。
[100] 接続オプションが Connection:
ヘッダーに現れずに対応するヘッダーだけがある場合、
そのヘッダーは誤って転送されてきたものかもしれず、
受信者が無視するべきです >>87。
[101] 新しい接続オプションを定義しようとする仕様書の著者は、 既存のヘッダー名を調査して、衝突しないように注意するべきです。 新しい接続オプションを定義すると、それと同じヘッダー名を別の目的に使うのはよくありませんから、 実質的にヘッダー名を予約することとなります。 >>87
[26] RFC 7230 は接続オプションと同名のヘッダーのことを表す用語を明示的に定義はしていませんが、 connection-specific header field という語を2回使っています。 RFC 7540 はこの語を採用しています。
[93] 送信者は、payload の受信者すべてに向けたヘッダーを
Connection:
に指定してはなりません >>87。
[94] 例えば Cache-Control:
は不適切です >>87。
[9] RFC 7231 はヘッダーの仕様書に対し、 Connection:
ヘッダーに指定するのが適当かどうか明記することを検討するよう求めています
>>8。
[97] 次のような値が接続オプションや connection-specific header field として使われています。
[20] >>97 に挙げたものの他、 C-Man:
や
C-Opt:
で宣言されたヘッダー接頭辞を使ったヘッダーも
Connection:
に指定しなければなりません。
[4] Upgrade:
や TE:
や Meter:
>>14 は、使用する場合必ず Connection:
に指定しなければならないと規定されています。
Content-Length
や Transfer-Encoding
や
Trailer
は、接続オプションとして使われることはないようです。
(串が書き換えることもできますが、基本的にはそのまま転送して良いものだからでしょう。)
ただし RFC 7540 は Transfer-Encoding
も
connection-specific header field だと述べています >>21。[12] Prefer:
は、 Connection:
に指定して当該接続のみに適用させられることが仕様書で敢えて言及されています >>11。
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 データがあります。
$ 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 かもしれません。
が見つかっています。
[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>