[2] Connection: ヘッダーの接続オプション
close は、送信者がその接続を要求・応答の完了後に閉じるつもりであることを表します
>>1。
仕様書
- [1] RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing ( 版) https://tools.ietf.org/html/rfc7230#page-52
- [6] RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing ( 版) https://tools.ietf.org/html/rfc7230#section-6.6
- [18] Message Headers ( 版) http://www.iana.org/assignments/message-headers/message-headers.xhtml
ヘッダー
[3] close は接続オプションですが、対応する
Close: ヘッダーはありません。
Connection: ヘッダーの値としてのみ使います。
[19] Close: ヘッダーは予約されています >>18。文脈
[7] 送信者は、現在の要求と応答の後に接続を閉じたいときは、
close 接続オプションを送信するべきです >>6。
[4] 持続接続に対応していないクライアントは、
要求メッセージに close 接続オプションを含めなければなりません
>>1。
[5] 持続接続に対応していない鯖は、 1xx
以外の応答メッセージに close
接続オプションを含めなければなりません
>>1。
処理モデル
[9] クライアントは、 close を送信した場合、
対応する最後の応答を読んだ後接続を閉じなければなりません >>6。
[13] 鯖は、 close を送信した場合、
その応答を送信した後接続を閉じはじめなければなりません >>6。
[8] クライアントは、 close を送信した場合、
その接続にそれ以上要求を送信してはなりません >>6。
[14] 鯖は、 close を送信した場合、
その接続の以降の要求を処理してはなりません >>6。
[15] クライアントは、 close を受信した場合、
接続を閉じ、その接続での要求の送信を停止しなければなりません
>>6。
[22] 更にクライアントはそれ以降の応答を受信しても無視するべきだと思われますが、
明記されていないようです。[16] クライアントは、パイプライン化して要求を送信していた途中で
close を受信した場合、それ以降の要求が処理されたと仮定するべきではありません
>>6。
[10] 鯖は、 close を受信した場合、
その要求に対する最後の応答を送信した後接続を閉じはじめなければなりません。
>>6
[11] 鯖は、 close を受信した場合、
その要求に対する最後の応答に close
接続オプションを含めるべきです >>6。
[12] 鯖は、 close を受信した場合、
その接続の以降の要求を処理してはなりません >>6。
実装
[20] Apache も nginx も、最後の応答には (要求が HTTP/1.0
であろうと HTTP/1.1 であろうと) Connection: close
を含めるようです。
[21] Apache も nginx も、(プロトコルの版の規定に従い)
HTTP/1.0 要求に対しても HTTP/1.1 応答を返します。[23] Chrome も Firefox も、Connection: close
を応答で受信したら、本体の受信が終わり次第すぐにTCP接続を閉じるようです。
関連
[17] HTTP接続、持続的接続、HTTPパイプラインも参照してください。