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

2. Architecture (アーキテクチャ)

HTTPは当初、文書指向の情報システム用のアプリケーション層プロトコルとして設計されました。HTTPのアーキテクチャはこの設計を反映しており、シンプルなリクエスト/レスポンスプロトコルとして定義されています。クライアントはリクエストメソッド、URI、プロトコルバージョンを含むリクエストメッセージをサーバーに送信し、続いてリクエスト修飾子、クライアント情報、および可能な表現内容を含むMIME風のメッセージを送信します。サーバーは、メッセージプロトコルバージョン、成功またはエラーコードを含むステータス行で応答し、続いてサーバー情報、エンティティメタ情報、および可能なエンティティコンテンツを含むMIME風のメッセージで応答します。

HTTPは基盤となるトランスポート層またはセッション層接続プロトコルから独立しています。HTTPは、リクエストとレスポンスの順序配信を保証できる信頼性の高いトランスポートのみを前提としています。HTTP/1.1メッセージの基盤となるトランスポートデータユニットへのマッピングは、本仕様の範囲外です。

HTTPは、閉鎖的な企業ネットワークからオープンなインターネット、組み込みデバイスから大規模なマルチプロセッサシステム、自動化されたエージェントから一般ユーザーのWebブラウザ、物理的にサーバーに近いクライアントから複数の仲介者とネットワークを横断するクライアントまで、さまざまな環境で使用されてきました。これらすべての環境において、実装はHTTPセマンティクスに関連する攻撃を回避または軽減するために慎重に設計する必要があります。

2.1. Client/Server Messaging (クライアント/サーバーメッセージング)​

HTTPは、クライアントとサーバー間でメッセージを交換することによって動作するステートレスなリクエスト/レスポンスプロトコルです。

HTTP-message   = start-line
                 *( header-field CRLF )
                 CRLF
                 [ message-body ]

クライアント (client) は、リクエストメソッド、URI、プロトコルバージョンの形式でHTTPリクエスト (request) をサーバーに送信し、続いてリクエスト修飾子、クライアント情報、および可能な表現内容を含むMIME風のメッセージを送信します。サーバー (server) は、メッセージプロトコルバージョンと成功またはエラーコードを含むステータス行の形式で1つ以上のHTTPレスポンス (response) で応答し、続いてサーバー情報、エンティティメタ情報、および可能な表現内容を含むMIME風のメッセージで応答します。

クライアントとサーバー間の接続はいずれの側からも閉じることができます。たとえば、クライアントは完全なレスポンスを受信した後に接続を閉じることができ、またはサーバーはタイムアウト期限が切れたときに接続を閉じることができます。

通常、HTTP通信は、クライアントが特定のサーバー上の特定のポートとのTCP/IP接続を確立することによって開始されます。HTTP/1.1では、接続の確立はURIスキームによって暗黙的に示されます。"http"スキーム (Section 2.7.1) は、TCP/IP接続を介してネットワークリソースを特定するために使用され、デフォルトでTCPポート80を使用しますが、他のポートも使用できます。

接続が確立されると、クライアントはHTTPリクエストメッセージをサーバーに送信します。

リクエストを受信して解釈した後、サーバーは1つ以上のHTTPレスポンスメッセージで応答します。

2.2. Implementation Diversity (実装の多様性)​

HTTPの"クライアント"または"サーバー"について話すとき、私たちはプログラムが一般的にできることのラベルではなく、特定の接続でそのプログラムが果たす役割を指しています。ユーザーエージェント (user agent) という用語は、リクエストを開始する任意のプログラムを指します。オリジンサーバー (origin server) という用語は、特定のターゲットリソースに対して権威ある応答を提供できるプログラムを指します。

HTTPは、Uniform Resource Identifiers (URI, 統一資源識別子) 標準 [RFC3986] に依存して、ターゲットリソース (Section 5.1) とリソース間の関係を示します。

メッセージは、インターネットメール [RFC5322] および Multipurpose Internet Mail Extensions (MIME, 多目的インターネットメール拡張) [RFC2045] で使用される形式に類似した形式で伝送されます。

2.3. Intermediaries (仲介者)​

HTTPでは、仲介者 (intermediaries) を使用してリクエストを満たすことができます。これは、可能な変換チェーンを通じてリクエストを渡すことによって行われます。3つの一般的なHTTP仲介者の形式があります: プロキシ (proxy)、ゲートウェイ (gateway)、およびトンネル (tunnel) です。

プロキシ (Proxy) は、クライアントによって選択されたメッセージ転送エージェントであり、通常はローカル構成ルールを介して、特定のタイプの絶対URIへのリクエストを受信し、必要に応じて変換を介してHTTPインターフェイス経由でこれらのリクエストを満たそうとします。

ゲートウェイ (Gateway) (「リバースプロキシ」とも呼ばれる) は、オリジンサーバー層の前面として機能し、オリジンサーバーの代わりにリクエストを受信する仲介者です。

トンネル (Tunnel) は、2つの接続間のブラインドリレーとして機能し、メッセージを変更せずに中継します。アクティブになると、トンネルはHTTP通信の一部とは見なされなくなります。

2.4. Caches (キャッシュ)​

キャッシュ (cache) は、以前のレスポンスメッセージのローカルストレージと、その保存、取得、および削除を制御するサブシステムです。キャッシュは、将来の同等のリクエストのレスポンス時間とネットワーク帯域幅の消費を削減するために、キャッシュ可能なレスポンスを保存します。

2.5. Conformance and Error Handling (適合性とエラー処理)​

本仕様は、送信者、受信者、クライアント、サーバー、ユーザーエージェント、仲介者、オリジンサーバー、プロキシ、ゲートウェイ、およびキャッシュの役割に対する適合性基準を定義しています。

メッセージを送信する実装 (つまり送信者) は、その送信者の役割に対するそのメッセージのプロトコル要素の構文とセマンティクスに準拠したメッセージのみを送信しなければなりません。

受信メッセージが無効であると思われる場合、またはメッセージ解析中にセマンティック無効性が検出された場合、受信者は適切なエラーステータスコードを含むレスポンスを送信するか (リクエストを受信したサーバーの場合)、またはメッセージを破棄して接続を閉じるか (すべての受信者の場合) すべきです。

2.6. Protocol Versioning (プロトコルバージョン管理)​

HTTPは、"<major>.<minor>"番号付けスキームを使用してプロトコルのバージョンを示します。本仕様はバージョン"1.1"を定義しています。

バージョン番号は、"."(ピリオドまたは小数点) で区切られた2つの小数桁で構成されます。最初の数字 ("major version", メジャーバージョン番号) は、HTTPメッセージ構文を示し、2番目の数字 ("minor version", マイナーバージョン番号) は、そのメジャーバージョン内で送信者が準拠し、将来の通信を理解できる最高のマイナーバージョンを示します。

2.7. Uniform Resource Identifiers (統一資源識別子)​

Uniform Resource Identifiers (URI, 統一資源識別子) [RFC3986] は、リソースを識別する手段としてHTTP全体で使用されます。

2.7.1. http URI Scheme (http URIスキーム)​

"http" URIスキームは、HTTPプロトコルを介してアクセス可能なリソースを識別するためにここで定義されています。

http-URI    = "http:" "//" authority path-abempty [ "?" query ]
              [ "#" fragment ]

2.7.2. https URI Scheme (https URIスキーム)​

"https" URIスキームは、暗号化された接続を介してアクセス可能なリソースを識別するためにここで定義されています。

https-URI   = "https:" "//" authority path-abempty [ "?" query ]
              [ "#" fragment ]

2.7.3. http and https URI Normalization and Comparison (httpおよびhttps URIの正規化と比較)​

"http"および"https"スキームは [RFC3986] で定義された一般的な構文に準拠しているため、そのようなURI参照の正規化と比較は、それぞれのスキームのデフォルトポート (httpの場合は80、httpsの場合は443) を使用して [RFC3986], [Section 6] で定義されたアルゴリズムの下で実行されます。

に最終更新