メインコンテンツまでスキップ

6. Connection Management (接続管理)

HTTPメッセージ伝送は、基盤となるトランスポートまたはセッション層接続プロトコルから独立しています。HTTPは、リクエストとレスポンスの順序配信を提供できる信頼性の高いトランスポートのみを前提としています。

6.1. Connection​

"Connection"ヘッダーフィールドにより、送信者は特定の接続に対して望ましい制御オプションを指定できます。

Connection        = 1#connection-option
connection-option = token

6.2. Establishment (確立)​

クライアントは、サーバーへの接続を確立する責任があります。HTTPには、接続自体を確立または識別するためのメッセージフレーミングの要件はありません。

6.3. Persistence (持続性)​

HTTP/1.1は、デフォルトで"持続的接続" (persistent connections) を使用し、単一の接続を介して複数のリクエストとレスポンスを送信できるようにします。HTTP実装は持続的接続をサポートすべきです。

6.3.1. Retrying Requests (リクエストの再試行)​

リクエストを自動的に再試行する場合、接続はリクエストメッセージの送信中 (またはレスポンスメッセージの待機中) に失敗する可能性があります。クライアントは、リクエストがべき等である ([RFC7231], [Section 4.2.2]) ことを確認できない限り、またはオリジンサーバーからメッセージを受信してサーバーが接続失敗前にリクエストを処理しなかったことを示す場合を除き、リクエストを自動的に再試行すべきではありません。

6.3.2. Pipelining (パイプライン化)​

持続的接続をサポートするクライアントは、リクエストを"パイプライン化" (pipeline) できます (つまり、各レスポンスを待たずに複数のリクエストを送信できます)。サーバーは、これらのパイプライン化されたリクエストに対するレスポンスを、リクエストを受信したのと同じ順序で送信しなければなりません。

6.4. Concurrency (並行性)​

クライアントは、サーバーへの並行接続の数を制限すべきです。

6.5. Failures and Timeouts (障害とタイムアウト)​

サーバーは通常、非アクティブな接続を維持しなくなるタイムアウト値を持っています。プロキシサーバーは、リソースを節約するために短いタイムアウト値を使用する場合があります。

6.6. Tear-down (切断)​

Connectionヘッダーフィールド (Section 6.1) は、"close"接続オプションを提供します。送信者はこれを使用して、現在のリクエスト/レスポンスの完了後に接続が閉じられることを通知します。

6.6.1. Retrying Requests (リクエストの再試行)​

クライアントは、リクエストの送信後に接続が閉じられた場合、べき等リクエストを再試行すべきです (クライアントがその接続で以前にリクエストを送信していた場合でも)。

6.6.2. Closure (クローズ)​

サーバーがTCP接続の即時クローズを実行する場合、クライアントが最後のHTTPレスポンスを読み取れないという重大なリスクがあります。

6.7. Upgrade (アップグレード)​

"Upgrade"ヘッダーフィールドは、HTTP/1.1から他の互換性のないプロトコルへの変換のためのシンプルなメカニズムを提供します。

Upgrade          = 1#protocol
protocol         = protocol-name ["/" protocol-version]
protocol-name    = token
protocol-version = token

サーバーは、101 (Switching Protocols, プロトコル切り替え) レスポンスを送信することによってプロトコルを切り替えることができます。

に最終更新