1. Introduction (はじめに)
1.1 Purpose (目的)
ハイパーテキスト転送プロトコル (Hypertext Transfer Protocol, HTTP) は、分散型、協調型、ハイパーメディア情報システムのためのアプリケーション層プロトコルです。HTTPは1990年以来、ワールドワイドウェブのグローバル情報イニシアチブで使用されてきました。HTTPの最初のバージョンであるHTTP/0.9は、インターネットを介した生データ転送のためのシンプルなプロトコルでした。RFC 1945 [6] で定義されたHTTP/1.0は、MIMEライクなメッセージ形式を採用し、転送データに関するメタ情報とリクエスト/レスポンスセマンティクスの修飾子を含めることでプロトコルを改善しました。しかし、HTTP/1.0は階層化プロキシ、キャッシング、持続的接続の必要性、またはバーチャルホストの影響を十分に考慮していませんでした。さらに、多くの不完全な実装のアプリケーションが「HTTP/1.0」を自称していたため、通信する2つのアプリケーションが互いの真の能力を判断できるように、プロトコルバージョンの変更が必要になりました。
本仕様書は「HTTP/1.1」と呼ばれるプロトコルを定義します。このプロトコルは、その機能の信頼性のある実装を確保するため、HTTP/1.0よりも厳格な要件を含んでいます。
実用的な情報システムには、単純な検索だけでなく、検索、フロントエンド更新、注釈などの機能が必要です。HTTPは、リクエストの目的を示すためのオープンエンドなメソッドとヘッダーフィールドのセットを許可します [47]。HTTPは、統一資源識別子 (Uniform Resource Identifier, URI) [3] が提供する参照仕様に基づいており、位置 (URL) [4] または名前 (URN) [20] として、メソッドを適用するリソースを示すために使用されます。メッセージは、多目的インターネットメール拡張 (Multipurpose Internet Mail Extensions, MIME) [7] によって定義された、インターネットメール [9] で使用される形式に似た形式で転送されます。
HTTPは、SMTP [16]、NNTP [13]、FTP [18]、Gopher [2]、WAIS [10] プロトコルによってサポートされるシステムを含む、他のインターネットシステムに接続するための、ユーザーエージェントとプロキシ/ゲートウェイ間の通信用の汎用プロトコルとしても使用されます。この方法により、HTTPは異なるアプリケーションからの利用可能なリソースへの基本的なハイパーメディアアクセスを可能にします。
1.2 Requirements (要件)
本文書におけるキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、RFC 2119 [34] の記述に従って解釈されるべきです。
実装が、その実装するプロトコルの1つ以上のMUSTまたはREQUIREDレベルの要件を満たせない場合、その実装は非準拠です。プロトコルのすべてのMUSTまたはREQUIREDレベルの要件とすべてのSHOULDレベルの要件を満たす実装は「無条件準拠 (unconditionally compliant)」と呼ばれます。すべてのMUSTレベルの要件を満たすが、プロトコルのすべてのSHOULDレベルの要件を満たさない実装は「条件付き準拠 (conditionally compliant)」と呼ばれます。
1.3 Terminology (用語)
本仕様書は、HTTP通信における参加者とオブジェクトが果たす役割を指すために多くの用語を使用します。
connection (接続) 通信目的で2つのプログラム間に確立されるトランスポート層の仮想回線。
message (メッセージ) HTTP通信の基本単位。第4節で定義された構文に従う構造化されたオクテットシーケンスで構成され、接続を介して転送されます。
request (リクエスト) 第5節で定義されたHTTPリクエストメッセージ。
response (レスポンス) 第6節で定義されたHTTPレスポンスメッセージ。
resource (リソース) 第3.2節で定義されているように、URIによって識別できるネットワークデータオブジェクトまたはサービス。リソースは、複数の表現（例えば、複数の言語、データ形式、サイズ、解像度）で利用可能であるか、他の方法で変化する可能性があります。
entity (エンティティ) リクエストまたはレスポンスのペイロードとして転送される情報。エンティティは、第7節で説明されているように、エンティティヘッダーフィールド形式のメタ情報とエンティティボディ形式のコンテンツで構成されます。
representation (表現) 第12節で説明されているように、コンテンツネゴシエーションの対象となる、レスポンスに含まれるエンティティ。特定のレスポンスステータスには、複数の関連する表現が存在する可能性があります。
content negotiation (コンテンツネゴシエーション) 第12節で説明されているように、リクエストを処理する際に適切な表現を選択するメカニズム。任意のレスポンス内のエンティティ表現は、ネゴシエート可能です（エラーレスポンスを含む）。
variant (バリアント) リソースは、任意の時点で1つ以上の表現が関連付けられている可能性があります。これらの各表現は「バリアント (variant)」と呼ばれます。「バリアント」という用語の使用は、リソースがコンテンツネゴシエーションの対象であることを必ずしも意味するものではありません。
client (クライアント) リクエストを送信する目的で接続を確立するプログラム。
user agent (ユーザーエージェント) リクエストを開始するクライアント。これらは通常、ブラウザ、エディター、ウェブクローラー (web-traversing robots)、またはその他のエンドユーザーツールです。
server (サーバー) レスポンスを送信してリクエストに応答するために接続を受け入れるアプリケーション。任意のプログラムは、クライアントとサーバーの両方である可能性があります。これらの用語は、特定の接続におけるプログラムが実行する役割のみを指し、プログラムの一般的な能力を指すものではありません。同様に、任意のサーバーは、各リクエストの性質に応じて動作を切り替えて、オリジンサーバー、プロキシ、ゲートウェイ、またはトンネルとして機能できます。
origin server (オリジンサーバー) 特定のリソースが存在する、または作成されるサーバー。
proxy (プロキシ) 他のクライアントに代わってリクエストを行うために、サーバーとクライアントの両方として機能する中間プログラム。リクエストは、内部で処理されるか、場合によっては変換されて他のサーバーに渡されます。プロキシは本仕様のクライアント要件とサーバー要件の両方を実装しなければなりません (MUST)。「透過プロキシ (transparent proxy)」は、プロキシ認証と識別に必要なもの以外、リクエストまたはレスポンスを変更しないプロキシです。「非透過プロキシ (non-transparent proxy)」は、ユーザーエージェントに追加のサービスを提供するために、リクエストまたはレスポンスを変更するプロキシです。例えば、グループアノテーションサービス、メディアタイプ変換、プロトコル削減、または匿名フィルタリングなどです。透過または非透過の動作が明示的に述べられていない限り、HTTPプロキシ要件は両方のタイプのプロキシに適用されます。
gateway (ゲートウェイ) 他のサーバーの中間として機能するサーバー。プロキシとは異なり、ゲートウェイはリクエストを受信すると、リクエストされたリソースのオリジンサーバーであるかのように動作します。リクエストするクライアントは、ゲートウェイと通信していることを認識しない可能性があります。
tunnel (トンネル) 2つの接続間のブラインドリレーとして機能する中間プログラム。一度アクティブになると、トンネルはHTTPリクエストによって開始される可能性がありますが、HTTP通信の当事者とは見なされません。リレーされる接続の両端が閉じられると、トンネルは存在しなくなります。
cache (キャッシュ) プログラムのレスポンスメッセージのローカルストレージ、およびそのメッセージのストレージ、取得、削除を制御するサブシステム。キャッシュは、将来の同等のリクエストのレスポンス時間とネットワーク帯域幅の消費を削減するために、キャッシュ可能なレスポンスを保存します。任意のクライアントまたはサーバーはキャッシュを含む可能性がありますが、トンネルとして機能するサーバーはキャッシュを使用できません。
cacheable (キャッシュ可能) キャッシュがレスポンスメッセージのコピーを保存し、後続のリクエストに応答するために使用することが許可されている場合、レスポンスはキャッシュ可能です。HTTPレスポンスがキャッシュ可能かどうかを判断するための規則は、第13節で定義されています。リソースがキャッシュ可能であっても、特定のキャッシュがそれをキャッシュすべきかどうかについて追加の制約がある可能性があります。
first-hand (ファーストハンド) レスポンスがオリジンサーバーから来る場合、1つ以上のプロキシを経由する可能性がありますが、そのレスポンスはファーストハンドです。レスポンスの有効性がオリジンサーバーによって検証されている場合も、レスポンスはファーストハンドです。
explicit expiration time (明示的な有効期限) オリジンサーバーが、エンティティがさらなる検証なしにキャッシュから返されるべきでない時刻。
heuristic expiration time (ヒューリスティック有効期限) 明示的な有効期限がない場合にキャッシュが割り当てる有効期限。
age (エイジ) レスポンスのエイジは、オリジンサーバーがレスポンスを送信した（またはレスポンスを正常に検証した）時点からの時間です。
freshness lifetime (鮮度ライフタイム) レスポンスが生成されてから有効期限までの時間の長さ。
fresh (フレッシュ) レスポンスのエイジがその鮮度ライフタイムをまだ超えていない場合、そのレスポンスはフレッシュです。
stale (ステール) レスポンスのエイジがその鮮度ライフタイムを超えている場合、そのレスポンスはステールです。
semantically transparent (意味論的に透過) キャッシュの使用が、リクエストクライアントまたはオリジンサーバーのいずれにも影響を与えない場合（パフォーマンスの改善を除く）、キャッシュの動作は意味論的に透過です。キャッシュが意味論的に透過な方法で動作する場合、クライアントが受信するレスポンスは、オリジンサーバーから直接送信されるレスポンスとまったく同じです（ホップバイホップ (hop-by-hop) ヘッダーフィールドを除く）。また、キャッシュは後続のリクエストの処理に影響を与えません。
validator (バリデーター) エンティティタグやLast-Modified時刻などのプロトコル要素。キャッシュエントリがエンティティの同等のコピーであるかどうかを判断するために使用されます。
upstream/downstream (上流/下流) 上流と下流は、メッセージの流れを説明します。すべてのメッセージは上流から下流に流れます。
inbound/outbound (インバウンド/アウトバウンド) インバウンドとアウトバウンドは、リクエストに対するリクエストとレスポンスのパスを指します。「インバウンド」は「オリジンサーバーに向かう」ことを意味し、「アウトバウンド」は「ユーザーエージェントに向かう」ことを意味します。
1.4 Overall Operation (全体的な動作)
HTTPプロトコルは、リクエスト/レスポンスプロトコルです。クライアントはサーバーにリクエストを送信し、リクエストはリクエストメソッド、URI、およびプロトコルバージョンの形式を取り、その後にリクエスト修飾子、クライアント情報、および場合によってはボディコンテンツを含むMIMEライクなメッセージが続き、接続を介して転送されます。サーバーはステータス行で応答し、メッセージのプロトコルバージョンと成功またはエラーコードを含み、その後にサーバー情報、エンティティメタ情報、および場合によってはエンティティボディコンテンツを含むMIMEライクなメッセージが続きます。ほとんどのHTTP通信はユーザーエージェントによって開始され、オリジンサーバー上のリソースに対するリクエストで構成されます。最も単純なケースでは、これはユーザーエージェント (UA) とオリジンサーバー (O) 間の単一の接続 (v) を介して実行できます。
request chain ------------------------>
UA -------------------v------------------- O
<----------------------- response chain
より複雑な状況は、リクエスト/レスポンスチェーンに1つ以上の中間者が存在する場合に発生します。中間者には3つの一般的な形式があります: プロキシ (proxy)、ゲートウェイ (gateway)、およびトンネル (tunnel)。プロキシは転送エージェントであり、URIの絶対形式でリクエストを受信し、メッセージの全部または一部を書き換え、URIで識別されるサーバーに再フォーマットされたリクエストを転送します。ゲートウェイは受信エージェントであり、他のサーバーの上層として機能し、必要に応じて、リクエストを基礎となるサーバーのプロトコルに変換できます。トンネルは2つの接続間のリレーポイントとして機能し、メッセージを変更しません。通信が中間者（ファイアウォールなど）を介して行われる必要がある場合、中間者がメッセージの内容を理解できない場合でも、トンネルが使用されます。
request chain -------------------------------------->
UA -----v----- A -----v----- B -----v----- C -----v----- O
<------------------------------------- response chain
上の図は、ユーザーエージェントとオリジンサーバーの間に3つの中間者（A、B、C）があることを示しています。リクエスト/レスポンスチェーン全体を通過するメッセージは、HTTP通信オプションの受け渡しメカニズムを使用して、接続のパラメータを決定します。
トンネルとして機能しない当事者は、キャッシュを使用してリクエストを満たすことができます。キャッシュがリクエスト/レスポンスチェーンに与える影響は、チェーン内のリクエストまたはレスポンスを傍受する可能性のあるさまざまなキャッシュのキャッシング要件に依存します。キャッシング動作とキャッシュ可能なレスポンスは、第13節で定義されています。
実際には、インターネット上および組織内に、さまざまなアーキテクチャパターンの構成が存在します。例えば、「全国アクセスプロバイダー」は通常、大規模なプロキシキャッシュを使用して、複数のユーザーエージェントが同じリクエストチェーンを介してオリジンサーバーにアクセスできるようにします。別の一般的な構成は、「リバースプロキシ」キャッシュです。これは、組織のホスト名の下にありますが、クライアントまたはサードパーティによって制御されます。リバースプロキシキャッシュは、ユーザーエージェントに対して透過的ですが、ネットワークを横断するトラフィックを節約するためにネットワークプロバイダーによって管理されることがよくあります。
HTTP通信は通常、TCP/IP接続で行われます。デフォルトポートはTCP 80 [19] ですが、他のポートも使用できます。これは、インターネットまたは他のネットワーク上の他のプロトコル上でHTTPを実装することを妨げるものではありません。HTTPは、信頼性のあるトランスポートのみを前提としています。このような保証を提供する任意のプロトコルを使用できます。HTTP/1.1リクエストとレスポンス構造の特定のトランスポートプロトコルのデータユニットへのマッピングは、本仕様の範囲外です。
HTTP/1.0では、ほとんどの実装が各リクエスト/レスポンス交換後に接続を閉じました。HTTP/1.1では、第8.1節で説明されているように、「持続的接続 (persistent connections)」を使用して、同じ接続を複数のリクエスト/レスポンス交換に使用できるメカニズムが許可されています。