Close:

Connection: close (HTTP)

[2] Connection: ヘッダー接続オプション close は、送信者がその接続要求応答の完了後に閉じるつもりであることを表します >>1

仕様書

ヘッダー

[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] Apachenginx も、最後の応答には (要求HTTP/1.0 であろうと HTTP/1.1 であろうと) Connection: close を含めるようです。

[21] Apachenginx も、(プロトコルの版の規定に従い) HTTP/1.0 要求に対しても HTTP/1.1 応答を返します。

[23] ChromeFirefox も、Connection: close応答で受信したら、本体の受信が終わり次第すぐにTCP接続を閉じるようです。

関連

[17] HTTP接続持続的接続HTTPパイプラインも参照してください。