1. Introduction (序論)
1.1. Purpose (目的)
ハイパーテキスト転送プロトコル (Hypertext Transfer Protocol, HTTP) は、ステートレス (Stateless) なアプリケーションレベルの要求/応答プロトコル (Request/Response Protocols) のファミリーであり、汎用インターフェース (Generic Interface)、拡張可能なセマンティクス (Extensible Semantics)、および自己記述型メッセージ (Self-Descriptive Messages) を共有して、ネットワークベースのハイパーテキスト情報システムとの柔軟な相互作用を可能にします。
HTTP は、提供されるリソースの種類に依存しない統一インターフェース (Uniform Interface) をクライアントに提示することで、サービスの実装の詳細を隠蔽します。同様に、サーバーは各クライアントの目的を認識する必要はありません。要求は、特定の種類のクライアントや事前に決定されたアプリケーションステップのシーケンスに関連付けられるのではなく、独立して考慮することができます。これにより、汎用実装を多くの異なるコンテキストで効果的に使用でき、相互作用の複雑さが軽減され、時間の経過とともに独立した進化が可能になります。
HTTP は、プロキシ (Proxies) とゲートウェイ (Gateways) が非HTTP情報システムをより汎用的なインターフェースに変換できる仲介プロトコル (Intermediation Protocol) としても設計されています。
この柔軟性の結果として、プロトコルはインターフェースの背後で発生することの観点から定義することができません。代わりに、通信の構文 (Syntax of Communication)、受信した通信の意図 (Intent)、および受信者の期待される動作 (Expected Behavior) を定義することに限定されます。通信が独立して考慮される場合、成功したアクションはサーバーが提供する観察可能なインターフェースの対応する変更に反映されるべきです。しかし、複数のクライアントが並行して、場合によっては相反する目的で行動する可能性があるため、そのような変更が単一の応答の範囲を超えて観察可能であることを要求することはできません。
1.2. History and Evolution (歴史と進化)
HTTP は、1990年の導入以来、ワールドワイドウェブ (World Wide Web) の主要な情報転送プロトコルです。当初は、指定されたパス名で識別される推定ハイパーテキスト文書の転送を要求する単一のメソッド (GET) を持つ、低レイテンシ要求のための単純なメカニズムでした。Web が成長するにつれて、HTTP は要求と応答をメッセージ内に封入し、MIME 風のメディアタイプ (Media Types) を使用して任意のデータ形式を転送し、仲介者 (Intermediaries) を通じて要求をルーティングするように拡張されました。これらのプロトコルは最終的に HTTP/0.9 と HTTP/1.0 として定義されました ([HTTP/1.0] を参照)。
HTTP/1.1 は、既存のテキストベースのメッセージング構文との互換性を保ちながらプロトコルの機能を改良し、インターネット全体での相互運用性 (Interoperability)、スケーラビリティ (Scalability)、および堅牢性 (Robustness) を向上させるように設計されました。これには、固定および動的 (チャンク化、Chunked) コンテンツの両方に対する長さベースのデータ区切り文字 (Length-Based Data Delimiters)、コンテンツネゴシエーション (Content Negotiation) のための一貫したフレームワーク、条件付き要求 (Conditional Requests) のための不透明バリデータ (Opaque Validators)、より良いキャッシュ一貫性のためのキャッシュ制御 (Cache Controls)、部分更新のための範囲要求 (Range Requests)、およびデフォルトの永続接続 (Persistent Connections) が含まれていました。HTTP/1.1 は1995年に導入され、1997年に標準化トラック (Standards Track) で公開され [RFC2068]、1999年に改訂され [RFC2616]、2014年に再度改訂されました ([RFC7230] から [RFC7235])。
HTTP/2 ([HTTP/2]) は、既存の TLS および TCP プロトコルの上に多重化セッション層 (Multiplexed Session Layer) を導入し、効率的なフィールド圧縮 (Field Compression) とサーバープッシュ (Server Push) を備えた並行 HTTP メッセージを交換します。HTTP/3 ([HTTP/3]) は、TCP の代わりに UDP 上の安全な多重化トランスポートとして QUIC を使用することで、並行メッセージのより大きな独立性を提供します。
HTTP の3つの主要バージョンはすべて、本文書で定義されるセマンティクスに依存しています。それぞれが使用コンテキストに応じて特定の利点と制限を持っているため、相互に廃止されていません。実装は、特定のコンテキストに最も適したトランスポートとメッセージング構文を選択することが期待されます。
この HTTP の改訂では、セマンティクス (本文書) とキャッシング ([CACHING]) の定義を現在の HTTP/1.1 メッセージング構文 ([HTTP/1.1]) から分離し、各主要プロトコルバージョンが同じコアセマンティクスを参照しながら独立して進化できるようにしています。
1.3. Core Semantics (コアセマンティクス)
HTTP は、リソース (Resource, セクション3.1) と相互作用するための統一インターフェースを提供します。リソースの種類、性質、または実装に関係なく、表現 (Representations, セクション3.2) を操作または転送するメッセージを送信することによって行われます。
各メッセージは要求 (Request) または応答 (Response) のいずれかです。クライアントは、その意図を伝える要求メッセージを構築し、それらのメッセージを識別された起点サーバー (Origin Server) に向けてルーティングします。サーバーは要求をリッスンし、受信した各メッセージを解析し、識別されたターゲットリソース (Target Resource) に関連してメッセージセマンティクスを解釈し、1つ以上の応答メッセージでその要求に応答します。クライアントは、受信した応答を調べて、その意図が実行されたかどうかを確認し、受信したステータスコード (Status Codes) とコンテンツに基づいて次に何をすべきかを決定します。
HTTP セマンティクスには、各要求メソッド (セクション9) で定義された意図、要求ヘッダーフィールド (Request Header Fields) で記述される可能性のあるこれらのセマンティクスの拡張、応答を記述するステータスコード (セクション15)、および応答フィールドで提供される可能性のあるその他の制御データとリソースメタデータ (Resource Metadata) が含まれます。
セマンティクスには、コンテンツが受信者によってどのように解釈されることを意図しているかを記述する表現メタデータ (Representation Metadata)、コンテンツ選択に影響を与える可能性のある要求ヘッダーフィールド、および総称して「コンテンツネゴシエーション」(Content Negotiation, セクション12) と呼ばれるさまざまな選択アルゴリズムも含まれます。
1.4. Specifications Obsoleted by This Document (本文書によって廃止される仕様)
| タイトル | 参照 | 参照先 |
|---|---|---|
| HTTP Over TLS | [RFC2818] | B.1 |
| HTTP/1.1 Message Syntax and Routing [*] | [RFC7230] | B.2 |
| HTTP/1.1 Semantics and Content | [RFC7231] | B.3 |
| HTTP/1.1 Conditional Requests | [RFC7232] | B.4 |
| HTTP/1.1 Range Requests | [RFC7233] | B.5 |
| HTTP/1.1 Authentication | [RFC7235] | B.6 |
| HTTP Status Code 308 (Permanent Redirect) | [RFC7538] | B.7 |
| HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields | [RFC7615] | B.8 |
| HTTP Client-Initiated Content-Encoding | [RFC7694] | B.9 |
表 1
[*] 本文書は、HTTP/1.1 メッセージング構文と接続管理から独立した RFC 7230 の部分のみを廃止します。RFC 7230 の残りの部分は「HTTP/1.1」[HTTP/1.1] によって廃止されます。