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

7. HTTPメッセージのルーティング (Routing HTTP Messages)

HTTPリクエストメッセージのルーティングは、ターゲットリソース、クライアントのプロキシ設定、およびインバウンド接続の確立または再利用に基づいて、各クライアントによって決定されます。対応する応答ルーティングは、同じ接続チェーンに沿ってクライアントに戻ります。

7.1. ターゲットリソースの決定 (Determining the Target Resource)​

HTTPはさまざまなアプリケーションで使用されていますが、ほとんどのクライアントは、汎用Webブラウザと同じリソース識別メカニズムと設定技術に依存しています。通信オプションがクライアントの設定にハードコードされている場合でも、それらの組み合わせ効果をURI参照 (Section 4.1) と考えることができます。

URI参照は、「ターゲットURI」(target URI) を取得するために絶対形式に解決されます。ターゲットURIは、フラグメント識別子がクライアント側の処理用に予約されているため、参照のフラグメントコンポーネント (もしあれば) を除外します ([URI], Section 3.5)。

「ターゲットリソース」(target resource) に対してアクションを実行するために、クライアントは、受信者が同じリソースを識別できるようにするために、解析されたターゲットURIの十分なコンポーネントを含むリクエストメッセージを送信します。歴史的な理由により、解析されたターゲットURIコンポーネント (総称して「リクエストターゲット」(request target) と呼ばれる) は、メッセージ制御データとHostヘッダーフィールド (Section 7.2) 内で送信されます。

リクエストターゲットコンポーネントがメソッド固有の形式になっている2つの異常なケースがあります：

  • CONNECT (Section 9.3.6) の場合、リクエストターゲットはトンネル宛先のホスト名とポート番号であり、コロンで区切られています。

  • OPTIONS (Section 9.3.7) の場合、リクエストターゲットは単一のアスタリスク ("*") にすることができます。

詳細については、それぞれのメソッド定義を参照してください。これらの形式は、他のメソッドと一緒に使用してはなりません (MUST NOT)。

クライアントのリクエストを受信すると、サーバーは、ローカル設定と着信接続コンテキストに従って、受信したコンポーネントからターゲットURIを再構築します。この再構築は、各メジャープロトコルバージョンに固有です。たとえば、[HTTP/1.1] のSection 3.3は、サーバーがHTTP/1.1リクエストのターゲットURIを決定する方法を定義しています。

注記： 以前の仕様では、再構成されたターゲットURIを別個の概念である「有効なリクエストURI」(effective request URI) として定義していました。

7.2. Host と :authority​

リクエストの「Host」ヘッダーフィールドは、ターゲットURIからホストとポート情報を提供し、オリジンサーバーが複数のホスト名に対するリクエストを処理しながらリソースを区別できるようにします。

HTTP/2 [HTTP/2] およびHTTP/3 [HTTP/3] では、Hostヘッダーフィールドは、場合によっては、リクエストの制御データの「:authority」疑似ヘッダーフィールドに置き換えられます。

Host = uri-host [ ":" port ] ; Section 4

ターゲットURIのauthority情報は、リクエストを処理するために重要です。ユーザーエージェントは、その情報を「:authority」疑似ヘッダーフィールドとして送信しない限り、リクエストでHostヘッダーフィールドを生成しなければなりません (MUST)。Hostを送信するユーザーエージェントは、それをリクエストのヘッダーセクションの最初のフィールドとして送信すべきです (SHOULD)。

たとえば、http://www.example.org/pub/WWW/ に対するオリジンサーバーへのGETリクエストは次のように始まります：

GET /pub/WWW/ HTTP/1.1
Host: www.example.org

ホストとポート情報はアプリケーションレベルのルーティングメカニズムとして機能するため、共有キャッシュを汚染したり、リクエストを意図しないサーバーにリダイレクトしようとするマルウェアの頻繁なターゲットです。インターセプトプロキシは、ホストとポート情報に依存して内部サーバーにリクエストをリダイレクトしたり、共有キャッシュのキャッシュキーとして使用する場合、インターセプトされた接続がそのホストの有効なIPアドレスをターゲットにしていることを最初に確認しないと、特に脆弱です。

7.3. インバウンドリクエストのルーティング (Routing Inbound Requests)​

ターゲットURIとそのオリジンが決定されると、クライアントは、目的のセマンティクスを達成するためにネットワークリクエストが必要かどうかを決定し、必要な場合は、そのリクエストがどこに向けられるかを決定します。

7.3.1. キャッシュへ (To a Cache)​

クライアントがキャッシュ [CACHING] を持っており、リクエストがそれによって満たされる場合、リクエストは通常最初にそこに向けられます。

7.3.2. プロキシへ (To a Proxy)​

リクエストがキャッシュによって満たされない場合、典型的なクライアントは、リクエストを満たすためにプロキシを使用するかどうかを決定するために、その設定をチェックします。プロキシ設定は実装依存ですが、多くの場合、URIプレフィックスマッチング、選択的authority マッチング、またはその両方に基づいており、プロキシ自体は通常「http」または「https」URIによって識別されます。

「http」または「https」プロキシが適用可能な場合、クライアントは、そのプロキシへの接続を確立 (または再利用) し、クライアントのターゲットURIと一致するリクエストターゲットを含むHTTPリクエストメッセージをそれに送信することによって、インバウンド接続します。

7.3.3. オリジンへ (To the Origin)​

適用可能なプロキシがない場合、典型的なクライアントは、識別されたリソースへのアクセスを取得するために、(ターゲットURIのスキームに固有の) ハンドラルーチンを呼び出します。これをどのように達成するかは、ターゲットURIスキームに依存し、その関連する仕様によって定義されます。

Section 4.3.2は、識別されたオリジンサーバーへのインバウンド接続を確立 (または再利用) し、クライアントのターゲットURIと一致するリクエストターゲットを含むHTTPリクエストメッセージをそれに送信することによって、「http」リソースへのアクセスを取得する方法を定義しています。

Section 4.3.3は、識別されたオリジンに対して権威あるオリジンサーバーへのインバウンドセキュア接続を確立 (または再利用) し、クライアントのターゲットURIと一致するリクエストターゲットを含むHTTPリクエストメッセージをそれに送信することによって、「https」リソースへのアクセスを取得する方法を定義しています。

7.4. 誤って向けられたリクエストの拒否 (Rejecting Misdirected Requests)​

サーバーがリクエストを受信し、そのターゲットURIを決定するのに十分に解析すると、サーバーは、リクエストを自分で処理するか、リクエストを別のサーバーに転送するか、クライアントを別のリソースにリダイレクトするか、エラーで応答するか、接続を切断するかを決定します。この決定は、リクエストまたは接続コンテキストに関する何にでも影響を受ける可能性がありますが、特に、サーバーがそのターゲットURIに対するリクエストを処理するように設定されているかどうか、および接続コンテキストがそのリクエストに適しているかどうかに向けられています。

たとえば、リクエストが意図的または偶然に誤って向けられ、受信したHostヘッダーフィールド内の情報が接続のホストまたはポートと異なる場合があります。接続が信頼されたゲートウェイからのものである場合、そのような不一致は予想される可能性があります。それ以外の場合、セキュリティフィルターをバイパスしたり、サーバーをだまして非公開コンテンツを配信させたり、キャッシュを汚染しようとする試みを示す可能性があります。メッセージルーティングに関するセキュリティ上の考慮事項については、Section 17を参照してください。

接続が信頼されたゲートウェイからのものでない限り、ターゲットURIのスキーム固有の要件が満たされていない場合、オリジンサーバーはリクエストを拒否しなければなりません (MUST)。特に、「https」リソースのリクエストは、Section 4.2.2で定義されているように、そのターゲットURIのオリジンに対して有効な証明書を介して保護された接続を介して受信されていない限り、拒否されなければなりません (MUST)。

応答の421 (Misdirected Request) ステータスコードは、オリジンサーバーが誤って向けられているように見えるため、リクエストを拒否したことを示します (Section 15.5.20)。

7.5. 応答の関連付け (Response Correlation)​

接続は、複数のリクエスト/応答交換に使用される可能性があります。リクエストメッセージと応答メッセージの間で関連付けるために使用されるメカニズムは、バージョンに依存します。HTTPの一部のバージョンはメッセージの暗黙的な順序付けを使用し、他のバージョンは明示的な識別子を使用します。

ステータスコードに関係なく (暫定応答を含む)、すべての応答は、リクエストが受信された後の任意の時点で送信できます。たとえリクエストがまだ完了していなくても。応答は、対応するリクエストが完了する前に完了できます (Section 6.1)。同様に、クライアントは応答を待つために特定の時間を待つことは期待されていません。合理的な期間内に応答が受信されない場合、クライアント (中間者を含む) はリクエストを放棄する可能性があります。

関連するリクエストをまだ送信している間に応答を受信するクライアントは、反対の明示的な指示を受信しない限り、そのリクエストの送信を続けるべきです (SHOULD) (たとえば、[HTTP/1.1] のSection 9.5および[HTTP/2] のSection 6.4を参照)。

7.6. メッセージ転送 (Message Forwarding)​

Section 3.7で説明されているように、中間者はHTTPリクエストと応答の処理においてさまざまな役割を果たすことができます。一部の中間者は、パフォーマンスまたは可用性を向上させるために使用されます。他の中間者は、アクセス制御またはコンテンツのフィルタリングに使用されます。HTTPストリームには、パイプアンドフィルターアーキテクチャに類似した特性があるため、中間者がストリームのいずれかの方向を強化 (または妨害) できる程度に固有の制限はありません。

中間者は、プロトコル要素が認識されない場合でも (たとえば、新しいメソッド、ステータスコード、またはフィールド名)、メッセージを転送することが期待されます。これは、ダウンストリーム受信者の拡張性を保持するためです。

トンネルとして機能していない中間者は、Section 7.6.1で指定されているように、Connectionヘッダーフィールドを実装し、着信接続のみを対象としたフィールドが転送されないように除外しなければなりません (MUST)。

中間者は、無限のリクエストループから保護されていない限り、メッセージを自分自身に転送してはなりません (MUST NOT)。一般に、中間者は、エイリアス、ローカルバリエーション、またはリテラルIPアドレスを含む独自のサーバー名を認識し、そのようなリクエストに直接応答すべきです。

HTTPメッセージは、増分処理またはダウンストリーム転送のためのストリームとして解析できます。ただし、一部の実装は、ネットワーク効率、セキュリティチェック、またはコンテンツ変換のために、メッセージ転送をバッファリングまたは遅延するため、送信者と受信者は部分メッセージの増分配信に依存できません。

7.6.1. Connection​

「Connection」ヘッダーフィールドを使用すると、送信者は現在の接続に対して必要な制御オプションをリストできます。

Connection        = #connection-option
connection-option = token

接続オプションは大文字と小文字を区別しません。

Connection以外のフィールドが現在の接続に関する制御情報を提供するために使用される場合、送信者はConnectionヘッダーフィールド内に対応するフィールド名をリストしなければなりません (MUST)。HTTPの一部のバージョンでは、そのような情報にフィールドを使用することが禁止されているため、Connectionフィールドを許可しないことに注意してください。

中間者は、メッセージが転送される前に受信したConnectionヘッダーフィールドを解析し、このフィールドの各connection-optionについて、connection-optionと同じ名前のヘッダーまたはトレーラーフィールドをメッセージから削除し、次にConnectionヘッダーフィールド自体を削除 (または転送されたメッセージの中間者独自の制御オプションに置き換える) しなければなりません (MUST)。

したがって、Connectionヘッダーフィールドは、即座の受信者のみを対象としたフィールド (「hop-by-hop」) と、チェーン上のすべての受信者を対象としたフィールド (「end-to-end」) を区別する宣言的な方法を提供し、メッセージを自己記述的にし、将来の接続固有の拡張機能が古い中間者によって盲目的に転送されることを恐れることなく展開できるようにします。

さらに、中間者は、それらがconnection-optionとして表示されるかどうかに関係なく、転送前に削除または置換が必要であることが知られているフィールドを、それらのフィールドのセマンティクスを適用した後、削除または置換すべきです (SHOULD)。これには以下が含まれますが、これらに限定されません：

  • Proxy-Connection ([HTTP/1.1] のAppendix C.2.2)
  • Keep-Alive ([RFC2068] のSection 19.7.1)
  • TE (Section 10.1.4)
  • Transfer-Encoding ([HTTP/1.1] のSection 6.1)
  • Upgrade (Section 7.8)

送信者は、コンテンツのすべての受信者を対象としたフィールドに対応する接続オプションを送信してはなりません (MUST NOT)。たとえば、Cache-Controlは接続オプションとして決して適切ではありません ([CACHING] のSection 5.2)。

接続オプションには、接続オプションに関連付けられたパラメータがない場合、接続固有のフィールドが必要ないため、必ずしもメッセージに存在するフィールドに対応しているわけではありません。対照的に、対応する接続オプションなしで受信された接続固有のフィールドは、通常、フィールドが中間者によって不適切に転送されたことを示し、受信者によって無視されるべきです。

フィールドに対応しない新しい接続オプションを定義する場合、仕様の作成者は、後の衝突を避けるために、とにかく対応するフィールド名を予約すべきです。このような予約されたフィールド名は、「ハイパーテキスト転送プロトコル (HTTP) フィールド名レジストリ」(Section 16.3.1) に登録されます。

7.6.2. Max-Forwards​

「Max-Forwards」ヘッダーフィールドは、TRACE (Section 9.3.8) およびOPTIONS (Section 9.3.7) リクエストメソッドで、リクエストがプロキシによって転送される回数を制限するメカニズムを提供します。これは、クライアントがチェーンの途中で失敗またはループしているように見えるリクエストをトレースしようとしている場合に役立ちます。

Max-Forwards = 1*DIGIT

Max-Forwards値は、このリクエストメッセージが転送できる残りの回数を示す10進整数です。

Max-Forwardsヘッダーフィールドを含むTRACEまたはOPTIONSリクエストを受信する各中間者は、リクエストを転送する前にその値をチェックして更新しなければなりません (MUST)。受信した値がゼロ (0) の場合、中間者はリクエストを転送してはなりません (MUST NOT)。代わりに、中間者は最終受信者として応答しなければなりません (MUST)。受信したMax-Forwards値がゼロより大きい場合、中間者は、転送されたメッセージで更新されたMax-Forwardsフィールドを生成しなければならず (MUST)、フィールド値は、a) 受信した値を1 (1) 減らした値、またはb) 受信者がMax-Forwardsに対してサポートする最大値のいずれか小さい方です。

受信者は、他のリクエストメソッドで受信したMax-Forwardsヘッダーフィールドを無視してもよい (MAY) です。

7.6.3. Via​

「Via」ヘッダーフィールドは、ユーザーエージェントとサーバーの間 (リクエスト時) またはオリジンサーバーとクライアントの間 (応答時) の中間プロトコルと受信者の存在を示します。これは、電子メールの「Received」ヘッダーフィールド ([RFC5322] のSection 3.6.7) と類似しています。Viaは、メッセージ転送の追跡、リクエストループの回避、およびリクエスト/応答チェーンに沿った送信者のプロトコル機能の識別に使用できます。

Via = #( received-protocol RWS received-by [ RWS comment ] )

received-protocol = [ protocol-name "/" ] protocol-version
                  ; Section 7.8を参照
received-by       = pseudonym [ ":" port ]
pseudonym         = token

Viaフィールド値の各メンバーは、メッセージを転送したプロキシまたはゲートウェイを表します。各中間者は、メッセージがどのように受信されたかについて独自の情報を追加するため、最終結果は転送受信者のシーケンスに従って順序付けられます。

プロキシは、転送する各メッセージで、以下に説明するように、適切なViaヘッダーフィールドを送信しなければなりません (MUST)。HTTP-to-HTTPゲートウェイは、各インバウンドリクエストメッセージで適切なViaヘッダーフィールドを送信しなければならず (MUST)、転送された応答メッセージでViaヘッダーフィールドを送信してもよい (MAY) です。

各中間者について、received-protocolは、メッセージのアップストリーム送信者が使用したプロトコルとプロトコルバージョンを示します。したがって、Viaフィールド値は、リクエスト/応答チェーンのアドバタイズされたプロトコル機能を記録し、ダウンストリーム受信者に見えるようにします。これは、Section 2.5で説明されているように、応答内または後のリクエスト内で安全に使用できる可能性がある後方互換性のない機能を判断するのに役立ちます。簡潔にするために、受信したプロトコルがHTTPの場合、protocol-nameは省略されます。

received-by部分は、通常、後続してメッセージを転送した受信者サーバーまたはクライアントのホストとオプションのポート番号です。ただし、実際のホストが機密情報と見なされる場合、送信者はそれを仮名に置き換えてもよい (MAY) です。ポートが提供されていない場合、受信者は、received-protocolのデフォルトポート (存在する場合) で受信されたことを意味すると解釈してもよい (MAY) です。

送信者は、User-AgentおよびServerヘッダーフィールドに類似して、各受信者のソフトウェアを識別するコメントを生成してもよい (MAY) です。ただし、Via内のコメントはオプションであり、受信者はメッセージを転送する前にそれらを削除してもよい (MAY) です。

たとえば、リクエストメッセージは、HTTP/1.0ユーザーエージェントから、「fred」というコード名の内部プロキシに送信され、それはHTTP/1.1を使用してp.example.netの公開プロキシにリクエストを転送し、それはwww.example.comのオリジンサーバーに転送することによってリクエストを完了します。www.example.comが受信するリクエストには、次のViaヘッダーフィールドが含まれます：

Via: 1.0 fred, 1.1 p.example.net

ネットワークファイアウォールを介したポータルとして使用される中間者は、明示的に有効にされていない限り、ファイアウォール領域内のホストの名前とポートを転送すべきではありません (SHOULD NOT)。有効になっていない場合、そのような中間者は、ファイアウォールの背後にあるホストの各received-byホストを、そのホストの適切な仮名に置き換えるべきです (SHOULD)。

中間者は、エントリが同一のreceived-protocol値を持つ場合、Viaヘッダーフィールドリストメンバーの順序付けられたサブシーケンスを単一のメンバーに結合してもよい (MAY) です。たとえば、

Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy

これは次のように縮小できます：

Via: 1.0 ricky, 1.1 mertz, 1.0 lucy

送信者は、すべてが同じ組織管理下にあり、ホストがすでに仮名に置き換えられていない限り、複数のリストメンバーを結合すべきではありません (SHOULD NOT)。送信者は、異なるreceived-protocol値を持つメンバーを結合してはなりません (MUST NOT)。

7.7. メッセージ変換 (Message Transformations)​

一部の中間者には、メッセージとそのコンテンツを変換する機能が含まれています。たとえば、プロキシは、キャッシュスペースを節約したり、低速リンクのトラフィック量を削減するために、画像形式間で変換する場合があります。ただし、これらの変換が医療画像や科学データ分析などの重要なアプリケーション向けのコンテンツに適用される場合、特に整合性チェックやデジタル署名を使用して受信したコンテンツがオリジナルと同一であることを保証する場合、運用上の問題が発生する可能性があります。

HTTP-to-HTTPプロキシは、セマンティック的に意味のある方法でメッセージを変更するように設計または設定されている場合、「変換プロキシ」(transforming proxy) と呼ばれます (つまり、通常のHTTP処理で必要とされるものを超えて、元の送信者にとって重要であるか、またはダウンストリーム受信者にとって潜在的に重要である方法でメッセージを変更する変更)。たとえば、変換プロキシは、共有注釈サーバー (ローカル注釈データベースへの参照を含めるように応答を変更する)、マルウェアフィルター、形式トランスコーダー、またはプライバシーフィルターとして機能している可能性があります。このような変換は、プロキシを選択したどのクライアント (またはクライアント組織) によっても望まれていると推定されます。

プロキシが完全修飾ドメイン名ではないホスト名を持つターゲットURIを受信した場合、リクエストを転送するときに受信したホスト名に独自のドメインを追加してもよい (MAY) です。ターゲットURIに完全修飾ドメイン名が含まれている場合、プロキシはホスト名を変更してはなりません (MUST NOT)。

プロキシは、その転送プロトコルで必要とされる場合を除き、受信したターゲットURIの「absolute-path」および「query」部分を次のインバウンドサーバーに転送するときに変更してはなりません (MUST NOT)。たとえば、HTTP/1.1経由でオリジンサーバーにリクエストを転送するプロキシは、リクエストメソッドに応じて、空のパスを「/」([HTTP/1.1] のSection 3.2.1) または「*」([HTTP/1.1] のSection 3.2.4) に置き換えます。

プロキシは、no-transformキャッシュディレクティブを含む応答メッセージのコンテンツ (Section 6.4) を変換してはなりません (MUST NOT) ([CACHING] のSection 5.2.2.6)。これは、コンテンツを変更しないメッセージ変換 (転送コーディングの追加または削除など ([HTTP/1.1] のSection 7)) には適用されないことに注意してください。

プロキシは、no-transformキャッシュディレクティブを含まないメッセージのコンテンツを変換してもよい (MAY) です。200 (OK) 応答のコンテンツを変換するプロキシは、応答ステータスコードを203 (Non-Authoritative Information) (Section 15.3.4) に変更することによって、変換が適用されたことをダウンストリーム受信者に通知できます。

プロキシは、フィールドの定義が特にそのような変更を許可している場合、または変更がプライバシーまたはセキュリティに必要であると見なされる場合を除き、通信チェーンのエンドポイント、リソース状態、または選択された表現 (コンテンツ以外) に関する情報を提供するヘッダーフィールドを変更すべきではありません (SHOULD NOT)。

7.8. Upgrade​

「Upgrade」ヘッダーフィールドは、同じ接続上でHTTP/1.1から他のプロトコルに移行するための簡単なメカニズムを提供することを目的としています。

クライアントは、最終応答を送信する前に、降順の優先順位で、名前付きプロトコルの1つ以上に切り替えるようサーバーを招待するために、リクエストのUpgradeヘッダーフィールドでプロトコル名のリストを送信してもよい (MAY) です。サーバーは、その接続で現在のプロトコルを引き続き使用したい場合、受信したUpgradeヘッダーフィールドを無視してもよい (MAY) です。Upgradeは、プロトコル変更を主張するために使用することはできません。

Upgrade          = #protocol

protocol         = protocol-name ["/" protocol-version]
protocol-name    = token
protocol-version = token

プロトコル名は推奨されるケースで登録されていますが、受信者は各protocol-nameをサポートされているプロトコルと一致させるときに、大文字と小文字を区別しない比較を使用すべきです (SHOULD)。

101 (Switching Protocols) 応答を送信するサーバーは、接続が切り替えられている新しいプロトコルを示すためにUpgradeヘッダーフィールドを送信しなければなりません (MUST)。複数のプロトコル層が切り替えられている場合、送信者はレイヤー昇順でプロトコルをリストしなければなりません (MUST)。サーバーは、対応するリクエストのUpgradeヘッダーフィールドでクライアントによって示されなかったプロトコルに切り替えてはなりません (MUST NOT)。サーバーは、クライアントが示した優先順位を無視し、リクエストの性質やサーバーの現在の負荷などの他の要因に基づいて新しいプロトコルを選択してもよい (MAY) です。

426 (Upgrade Required) 応答を送信するサーバーは、降順の優先順位で、受け入れ可能なプロトコルを示すためにUpgradeヘッダーフィールドを送信しなければなりません (MUST)。

サーバーは、将来のリクエストに適した場合、降順の優先順位で、リストされたプロトコルへのアップグレードのサポートを実装していることをアドバタイズするために、他の応答でUpgradeヘッダーフィールドを送信してもよい (MAY) です。

以下は、クライアントが送信する仮想的な例です：

GET /hello HTTP/1.1
Host: www.example.com
Connection: upgrade
Upgrade: websocket, IRC/6.9, RTA/x11

プロトコル変更後のアプリケーションレベルの通信の機能と性質は、選択された新しいプロトコルに完全に依存します。ただし、101 (Switching Protocols) 応答を送信した直後、サーバーは、新しいプロトコル内でその同等のものを受信したかのように、元のリクエストへの応答を続けることが期待されます (つまり、プロトコルが変更された後、サーバーにはまだ満たすべき未解決のリクエストがあり、リクエストを繰り返す必要なく実行することが期待されます)。

たとえば、UpgradeヘッダーフィールドがGETリクエストで受信され、サーバーがプロトコルを切り替えることを決定した場合、最初にHTTP/1.1で101 (Switching Protocols) メッセージで応答し、その直後にターゲットリソース上のGETへの応答の新しいプロトコルの同等のものをすぐに続けます。これにより、追加のラウンドトリップのレイテンシコストなしに、HTTPと同じセマンティクスを持つプロトコルに接続をアップグレードできます。サーバーは、受信したメッセージセマンティクスが新しいプロトコルによって尊重できない限り、プロトコルを切り替えてはなりません (MUST NOT)。OPTIONSリクエストは、任意のプロトコルによって尊重できます。

以下は、上記の仮想的なリクエストに対する応答の例です：

HTTP/1.1 101 Switching Protocols
Connection: upgrade
Upgrade: websocket

[... データストリームがwebsocketに切り替わり、適切な応答
(新しいプロトコルで定義されている) が「GET /hello」リクエストに対して送信されます ...]

Upgradeの送信者は、中間者にこのフィールドを転送しないように通知するために、Connectionヘッダーフィールド (Section 7.6.1) で「Upgrade」接続オプションも送信しなければなりません (MUST)。HTTP/1.0リクエストでUpgradeヘッダーフィールドを受信するサーバーは、そのUpgradeフィールドを無視しなければなりません (MUST)。

クライアントは、リクエストメッセージを完全に送信するまで、接続でアップグレードされたプロトコルの使用を開始できません (つまり、クライアントはメッセージの途中で送信しているプロトコルを変更できません)。サーバーがUpgradeと「100-continue」期待値 (Section 10.1.1) を持つExpectヘッダーフィールドの両方を受信した場合、サーバーは101 (Switching Protocols) 応答を送信する前に100 (Continue) 応答を送信しなければなりません (MUST)。

Upgradeヘッダーフィールドは、既存の接続の上でプロトコルを切り替えることにのみ適用されます。基礎となる接続 (トランスポート) プロトコルを切り替えたり、既存の通信を別の接続に切り替えるために使用することはできません。これらの目的には、3xx (Redirection) 応答 (Section 15.4) を使用する方が適切です。

この仕様は、Section 2.5のHTTPバージョンルールおよびこの仕様の将来の更新で定義されているように、ハイパーテキスト転送プロトコルファミリによる使用のために「HTTP」プロトコル名のみを定義しています。追加のプロトコル名は、Section 16.7で定義された登録手順を使用して登録されるべきです。

に最終更新