3. Terminology and Core Concepts (用語とコア概念)
HTTP は World Wide Web (WWW) アーキテクチャのために作成され、世界規模のハイパーテキストシステムのスケーラビリティニーズをサポートするために時間とともに進化してきました。そのアーキテクチャの多くは、HTTP を定義するために使用される用語に反映されています。
3.1. Resources (リソース)
HTTP リクエストのターゲットは「リソース」(Resource) と呼ばれます。HTTP はリソースの性質を制限しません。リソースと相互作用するために使用される可能性のあるインターフェースを定義するだけです。ほとんどのリソースは、セクション4で説明されているように、統一リソース識別子 (Uniform Resource Identifier, URI) によって識別されます。
HTTP の設計目標の1つは、リソース識別を要求セマンティクスから分離することです。これは、要求セマンティクスを要求メソッド (セクション9) といくつかの要求修正ヘッダーフィールドに委ねることで可能になります。リソースは、要求のメソッドのセマンティクスと矛盾する方法で要求を処理することはできません。たとえば、リソースの URI が安全でないセマンティクスを暗示する可能性がありますが、クライアントは、安全なメソッド (Safe Method) で要求を処理する際にリソースが安全でないアクションを回避することを期待できます (セクション9.2.1を参照)。
HTTP は、ターゲットリソース (セクション7.1) とリソース間の関係を示すために、統一リソース識別子 (URI) 標準 [URI] に依存しています。
3.2. Representations (表現)
「表現」(Representation) は、プロトコルを介して容易に伝達できる形式で、与えられたリソースの過去、現在、または望ましい状態を反映することを意図した情報です。表現は、表現メタデータ (Representation Metadata) のセットと、潜在的に無制限の表現データストリーム (Representation Data, セクション8) で構成されます。
HTTP は、リソース自体を転送するのではなく、リソース状態の転送可能な表現に関する通信を定義することにより、その統一インターフェースの背後で「情報隠蔽」(Information Hiding) を可能にします。これにより、URI で識別されるリソースは、「ラグナビーチの現在の天気」のような時間関数を含む任意のものである可能性がありますが、メッセージが生成される時点でそのリソースを表す情報を提供する可能性があります [REST]。
統一インターフェースは、反対側の独立したアクターへのメッセージの通信を通じてのみ、何かを観察し作用することができる窓に似ています。私たちの通信において、そのものの現在または望ましい状態を表現する (「代わりをする」) ために、共有抽象化が必要です。表現がハイパーテキストである場合、リソース状態の表現と、受信者の将来の相互作用を導くのに役立つ処理命令の両方を提供できます。
ターゲットリソースには、それぞれがリソースの現在の状態を反映することを意図した複数の表現が提供される、または生成できる可能性があります。通常、コンテンツネゴシエーション (Content Negotiation, セクション12) に基づくアルゴリズムが使用され、それらの表現の1つを特定の要求に最も適用可能なものとして選択します。この「選択された表現」(Selected Representation) は、条件付き要求 (セクション13) を評価し、GET (セクション9.3.1) への 200 (OK)、206 (Partial Content)、および 304 (Not Modified) 応答のコンテンツを構築するためのデータとメタデータを提供します。
3.3. Connections, Clients, and Servers (接続、クライアント、およびサーバー)
HTTP は、信頼性の高いトランスポート層またはセッション層の「接続」(Connection) 上で動作するクライアント/サーバープロトコルです。
HTTP「クライアント」(Client) は、1つ以上の HTTP 要求を送信する目的でサーバーへの接続を確立するプログラムです。HTTP「サーバー」(Server) は、HTTP 応答を送信することにより HTTP 要求にサービスを提供するために接続を受け入れるプログラムです。
クライアントとサーバーという用語は、これらのプログラムが特定の接続で実行する役割のみを指します。同じプログラムが、一部の接続ではクライアントとして、他の接続ではサーバーとして機能する場合があります。
HTTP はステートレスプロトコル (Stateless Protocol) として定義されています。つまり、各要求メッセージのセマンティクスは独立して理解でき、接続とその上のメッセージとの関係は、それらのメッセージの解釈に影響を与えません。たとえば、CONNECT 要求 (セクション9.3.6) または Upgrade ヘッダーフィールド (セクション7.8) を含む要求は、接続の最初のメッセージだけでなく、いつでも発生する可能性があります。多くの実装は、プロキシ接続を再利用したり、複数のサーバー間で要求を動的に負荷分散したりするために、HTTP のステートレス設計に依存しています。
その結果、サーバーは、接続が安全であり、そのエージェント専用でない限り、同じ接続上の2つの要求が同じユーザーエージェントからのものであると仮定してはなりません (MUST NOT)。一部の非標準 HTTP 拡張 (たとえば、[RFC4559]) は、この要件に違反することが知られており、セキュリティと相互運用性の問題を引き起こしています。
3.4. Messages (メッセージ)
HTTP は、接続を介して「メッセージ」(Messages) を交換するためのステートレス要求/応答プロトコルです。「送信者」(Sender) および「受信者」(Recipient) という用語は、それぞれ、特定のメッセージを送信または受信する任意の実装を指します。
クライアントは、メソッド (セクション9) と要求ターゲット (セクション7.1) を含む「要求」(Request) メッセージの形式でサーバーに要求を送信します。要求には、要求修飾子、クライアント情報、および表現メタデータのためのヘッダーフィールド (セクション6.3)、メソッドに従って処理されることを意図したコンテンツ (セクション6.4)、およびコンテンツの送信中に収集された情報を伝達するためのトレーラーフィールド (セクション6.5) も含まれる場合があります。
サーバーは、それぞれがステータスコード (セクション15) を含む1つ以上の「応答」(Response) メッセージを送信することにより、クライアントの要求に応答します。応答には、サーバー情報、リソースメタデータ、および表現メタデータのためのヘッダーフィールド、ステータスコードに従って解釈されるコンテンツ、およびコンテンツの送信中に収集された情報を伝達するためのトレーラーフィールドも含まれる場合があります。
3.5. User Agents (ユーザーエージェント)
「ユーザーエージェント」(User Agent) という用語は、要求を開始するさまざまなクライアントプログラムのいずれかを指します。
ユーザーエージェントの最も馴染みのある形式は汎用 Web ブラウザですが、これは実装のごく一部にすぎません。その他の一般的なユーザーエージェントには、スパイダー (Web 巡回ロボット)、コマンドラインツール、ビルボードスクリーン、家電、スケール、電球、ファームウェア更新スクリプト、モバイルアプリ、およびさまざまな形状とサイズの通信デバイスが含まれます。
ユーザーエージェントであることは、要求の時点で人間のユーザーがソフトウェアエージェントと直接対話していることを意味するものではありません。多くの場合、ユーザーエージェントは、バックグラウンドで実行し、後で検査するために結果を保存する (または、興味深いまたは誤っている可能性のある結果のサブセットのみを保存する) ようにインストールまたは構成されています。たとえば、スパイダーには通常、開始 URI が与えられ、ハイパーテキストグラフとして Web をクロールする際に特定の動作に従うように構成されています。
多くのユーザーエージェントは、ユーザーに対話的な提案を行うことができない、または行わないことを選択するか、セキュリティまたはプライバシーの懸念に対する適切な警告を提供しません。この仕様がユーザーへのエラー報告を要求する少数のケースでは、そのような報告がエラーコンソールまたはログファイルでのみ観察可能であることは許容されます。同様に、自動化されたアクションを続行する前にユーザーによって確認されることを要求する要件は、事前構成の選択、実行時オプション、または安全でないアクションの単純な回避によって満たされる可能性があります。ユーザーがすでにその選択を行っている場合、確認は特定のユーザーインターフェースまたは通常の処理の中断を意味するものではありません。
3.6. Origin Server (起点サーバー)
「起点サーバー」(Origin Server) という用語は、特定のターゲットリソースに対して権威ある応答 (Authoritative Responses) を発信できるプログラムを指します。
起点サーバーの最も馴染みのある形式は、大規模な公開ウェブサイトです。ただし、ユーザーエージェントがブラウザと同一視されるのと同様に、すべての起点サーバーが同じであると誤解されやすいです。一般的な起点サーバーには、ホームオートメーションユニット、構成可能なネットワークコンポーネント、オフィス機器、自律ロボット、ニュースフィード、交通カメラ、リアルタイム広告セレクタ、およびビデオオンデマンドプラットフォームも含まれます。
ほとんどの HTTP 通信は、URI によって識別される何らかのリソースの表現の取得要求 (GET) で構成されます。最も単純なケースでは、これはユーザーエージェント (UA) と起点サーバー (O) の間の単一の双方向接続 (===) を介して実行される可能性があります。
request >
UA ======================================= O
< response
図 1
3.7. Intermediaries (仲介者)
HTTP は、接続のチェーンを通じて要求を満たすために仲介者 (Intermediaries) の使用を可能にします。HTTP「仲介者」には、プロキシ (Proxy)、ゲートウェイ (Gateway)、およびトンネル (Tunnel) の3つの一般的な形式があります。場合によっては、単一の仲介者が、各要求の性質に基づいて動作を切り替えながら、起点サーバー、プロキシ、ゲートウェイ、またはトンネルとして機能する場合があります。
> > > >
UA =========== A =========== B =========== C =========== O
< < < <
図 2
上の図は、ユーザーエージェントと起点サーバーの間の3つの仲介者 (A、B、および C) を示しています。チェーン全体を移動する要求または応答メッセージは、4つの別々の接続を通過します。一部の HTTP 通信オプションは、最も近い非トンネル隣接との接続にのみ適用される場合、チェーンのエンドポイントにのみ適用される場合、またはチェーンに沿ったすべての接続に適用される場合があります。図は線形ですが、各参加者は複数の同時通信に従事している可能性があります。たとえば、B は、A の要求を処理すると同時に、A 以外の多くのクライアントから要求を受信したり、C 以外のサーバーに要求を転送したりする場合があります。同様に、後の要求は、多くの場合、負荷分散のための動的構成に基づいて、異なる接続パスを通じて送信される場合があります。
「上流」(Upstream) および「下流」(Downstream) という用語は、メッセージフローに関連する方向要件を説明するために使用されます。すべてのメッセージは上流から下流に流れます。「インバウンド」(Inbound) および「アウトバウンド」(Outbound) という用語は、要求ルートに関連する方向要件を説明するために使用されます。インバウンドは「起点サーバーに向かって」を意味し、アウトバウンドは「ユーザーエージェントに向かって」を意味します。
「プロキシ」(Proxy) は、通常、ローカル構成ルールを介してクライアントによって選択される、ある種の絶対 URI の要求を受信し、HTTP インターフェースを通じた変換を介してそれらの要求を満たそうとするメッセージ転送エージェントです。一部の変換は、「http」URI のプロキシ要求のように最小限ですが、他の要求では、まったく異なるアプリケーション層プロトコルとの間の変換が必要になる場合があります。プロキシは、セキュリティサービス、注釈サービス、または共有キャッシュのために、組織の HTTP 要求を共通の仲介者を通じてグループ化するためによく使用されます。一部のプロキシは、セクション7.7で説明されているように、転送中に選択されたメッセージまたはコンテンツに変換を適用するように設計されています。
「ゲートウェイ」(Gateway) (別名「リバースプロキシ」Reverse Proxy) は、アウトバウンド接続の起点サーバーとして機能するが、受信した要求を変換し、それらを別のサーバーまたは複数のサーバーにインバウンド転送する仲介者です。ゲートウェイは、レガシーまたは信頼されていない情報サービスをカプセル化したり、「アクセラレータ」(Accelerator) キャッシングを通じてサーバーパフォーマンスを向上させたり、複数のマシンにわたる HTTP サービスのパーティショニングまたは負荷分散を可能にしたりするためによく使用されます。
起点サーバーに適用されるすべての HTTP 要件は、ゲートウェイのアウトバウンド通信にも適用されます。ゲートウェイは、この仕様の範囲外の HTTP へのプライベート拡張を含む、任意のプロトコルを使用してインバウンドサーバーと通信します。ただし、サードパーティの HTTP サーバーと相互運用したい HTTP-to-HTTP ゲートウェイは、ゲートウェイのインバウンド接続でユーザーエージェント要件に準拠する必要があります。
「トンネル」(Tunnel) は、メッセージを変更することなく2つの接続間の盲目的なリレーとして機能します。アクティブになると、トンネルは HTTP 通信の当事者とは見なされませんが、トンネルは HTTP 要求によって開始された可能性があります。トンネルは、中継された接続の両端が閉じられると存在しなくなります。トンネルは、共有ファイアウォールプロキシを通じて機密通信を確立するためにトランスポート層セキュリティ (Transport Layer Security, TLS, [TLS13]) が使用される場合など、仲介者を通じて仮想接続を拡張するために使用されます。
仲介者の上記のカテゴリは、HTTP 通信の参加者として機能するもののみを考慮しています。ネットワークプロトコルスタックの下位層で動作し、メッセージ送信者の知識または許可なしに HTTP トラフィックをフィルタリングまたはリダイレクトできる仲介者もあります。ネットワーク仲介者は (プロトコルレベルで) パス上の攻撃者と区別がつかず、HTTP セマンティクスを誤って違反することにより、セキュリティの欠陥や相互運用性の問題を引き起こすことがよくあります。
たとえば、「傍受プロキシ」(Interception Proxy) [RFC3040] (一般に「透過プロキシ」Transparent Proxy [RFC1919] としても知られている) は、クライアントによって選択されていないため、HTTP プロキシとは異なります。代わりに、傍受プロキシは、発信 TCP ポート80パケット (および時折他の一般的なポートトラフィック) をフィルタリングまたはリダイレクトします。傍受プロキシは、非ローカルインターネットサービスの使用を許可する前にアカウントサブスクリプションを強制する手段として公共ネットワークアクセスポイントに、および企業ファイアウォール内でネットワーク使用ポリシーを強制するために一般的に見られます。
3.8. Caches (キャッシュ)
「キャッシュ」(Cache) は、以前の応答メッセージのローカルストアと、そのメッセージの保存、取得、および削除を制御するサブシステムです。キャッシュは、将来の同等の要求の応答時間とネットワーク帯域幅消費を削減するために、キャッシュ可能な応答を保存します。任意のクライアントまたはサーバーがキャッシュを使用してもよい (MAY) ですが、トンネルとして機能している間はキャッシュを使用できません。
キャッシュの効果は、チェーンに沿った参加者の1つがその要求に適用可能なキャッシュされた応答を持っている場合、要求/応答チェーンが短縮されることです。以下は、B が UA または A によってキャッシュされていない要求に対して O (C 経由) からの以前の応答のキャッシュされたコピーを持っている場合の結果のチェーンを示しています。
> >
UA =========== A =========== B - - - - - - C - - - - - - O
< <
図 3
応答が「キャッシュ可能」(Cacheable) であるのは、キャッシュが後続の要求に答えるために使用するために応答メッセージのコピーを保存することが許可されている場合です。応答がキャッシュ可能である場合でも、クライアントまたは起点サーバーによって、そのキャッシュされた応答を特定の要求に使用できる場合に追加の制約が課される場合があります。キャッシュ動作とキャッシュ可能な応答に対する HTTP 要件は [CACHING] で定義されています。
World Wide Web 全体および大規模組織内に展開されているキャッシュのアーキテクチャと構成には、さまざまなものがあります。これらには、帯域幅を節約し、レイテンシを削減するためのプロキシキャッシュの国家階層、人気のあるサイトの地域およびグローバル配布を最適化するためにゲートウェイキャッシングを使用するコンテンツ配信ネットワーク、キャッシュエントリをブロードキャストまたはマルチキャストする協調システム、オフラインまたは高レイテンシ環境で使用するための事前にフェッチされたキャッシュエントリのアーカイブなどが含まれます。
3.9. Example Message Exchange (メッセージ交換の例)
以下の例は、URI http://www.example.com/hello.txt に対する GET 要求 (セクション9.3.1) の典型的な HTTP/1.1 メッセージ交換を示しています。
クライアント要求:
GET /hello.txt HTTP/1.1
User-Agent: curl/7.64.1
Host: www.example.com
Accept-Language: en, mi
サーバー応答:
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain
Hello World! My content includes a trailing CRLF.