2. Conformance (適合性)
2.1. Syntax Notation (構文表記)
本仕様は、[RFC5234] の拡張バッカス・ナウア記法 (Augmented Backus-Naur Form, ABNF) 表記を使用し、[RFC7405] で定義された文字列の大文字小文字の区別の表記で拡張されています。
また、セクション5.6.1で定義されたリスト拡張も使用します。これにより、"#" 演算子を使用してカンマ区切りリストをコンパクトに定義できます ("*" 演算子が繰り返しを示すのと同様)。付録Aは、すべてのリスト演算子を標準ABNF表記に展開した収集された文法を示しています。
慣例として、"obs-" で始まるABNFルール名は、歴史的な理由で現れる廃止された文法規則を示します。
以下のコアルールは、[RFC5234] の付録B.1で定義されているように、参照によって含まれています: ALPHA (文字)、CR (キャリッジリターン)、CRLF (CR LF)、CTL (制御文字)、DIGIT (10進数0-9)、DQUOTE (二重引用符)、HEXDIG (16進数0-9/A-F/a-f)、HTAB (水平タブ)、LF (ラインフィード)、OCTET (任意の8ビットデータシーケンス)、SP (スペース)、およびVCHAR (任意の可視US-ASCII文字)。
セクション5.6は、フィールド値のいくつかの汎用構文コンポーネントを定義します。
本仕様は、[RFC6365] で定義されている用語「character」(文字)、「character encoding scheme」(文字エンコーディングスキーム)、「charset」(文字セット)、および「protocol element」(プロトコル要素) を使用します。
2.2. Requirements Notation (要件表記)
本文書のキーワード「MUST」(しなければならない)、「MUST NOT」(してはならない)、「REQUIRED」(必須である)、「SHALL」(しなければならない)、「SHALL NOT」(してはならない)、「SHOULD」(すべきである)、「SHOULD NOT」(すべきでない)、「RECOMMENDED」(推奨される)、「NOT RECOMMENDED」(推奨されない)、「MAY」(してもよい)、および「OPTIONAL」(任意である) は、BCP 14 [RFC2119] [RFC8174] に記載されているように解釈されるものとします。これらがすべて大文字で表示される場合に限ります。
本仕様は、HTTP通信における参加者の役割に応じて適合性基準を対象としています。したがって、要件は、要件によって制約される動作に応じて、送信者 (Senders)、受信者 (Recipients)、クライアント (Clients)、サーバー (Servers)、ユーザーエージェント (User Agents)、仲介者 (Intermediaries)、起点サーバー (Origin Servers)、プロキシ (Proxies)、ゲートウェイ (Gateways)、またはキャッシュ (Caches) に配置されます。単一の通信の範囲を超えて適用される場合、実装 (Implementations)、リソース所有者 (Resource Owners)、およびプロトコル要素登録 (Protocol Element Registrations) に追加の要件が配置されます。
動詞「generate」(生成する) は、要件がプロトコル要素を作成する実装にのみ適用される場合に「send」(送信する) の代わりに使用されます。受信した要素を下流に転送する実装には適用されません。
実装は、HTTPで果たす役割に関連するすべての要件に準拠している場合、適合 (Conformant) していると見なされます。
送信者は、対応するABNFルールで定義された文法に一致しないプロトコル要素を生成してはなりません (MUST NOT)。特定のメッセージ内で、送信者は、他の役割の参加者によってのみ生成が許可されているプロトコル要素または構文の代替を生成してはなりません (MUST NOT) (つまり、送信者がそのメッセージに対して持っていない役割)。
HTTPへの適合には、使用中のプロトコルバージョンの特定のメッセージング構文への適合と、送信されたプロトコル要素のセマンティクスへの適合の両方が含まれます。たとえば、HTTP/1.1への適合を主張するが、HTTP/1.1受信者に必要な機能を認識できないクライアントは、それらの主張に従って応答を調整するサーバーと相互運用できません。コンテンツネゴシエーション (Content Negotiation) やユーザー選択の拡張機能など、ユーザーの選択を反映する機能は、プロトコルストリームを超えてアプリケーションの動作に影響を与える可能性があります。ユーザーの選択を不正確に反映するプロトコル要素を送信すると、ユーザーを混乱させ、選択を阻害します。
実装がセマンティック適合に失敗した場合、その実装のメッセージの受信者は、最終的にそれに応じて動作を調整するための回避策 (Workarounds) を開発します。回避策が問題のある実装に限定されている場合、受信者はこのプロトコルに適合したままでそのような回避策を採用してもよい (MAY) です。たとえば、サーバーはUser-Agentフィールド値の一部をスキャンすることが多く、ユーザーエージェントはServerフィールド値をスキャンすることが多く、既知のバグや不適切に選択されたデフォルトに関して自身の動作を調整します。
2.3. Length Requirements (長さ要件)
受信者は、受信したプロトコル要素を防御的に解析すべきであり (SHOULD)、要素がそのABNF文法に準拠し、妥当なバッファサイズ内に収まるという限定的な期待のみを持つべきです。
HTTPは、多くのプロトコル要素に対して特定の長さ制限を持っていません。これは、適切な長さが、展開コンテキストと実装の目的に応じて大きく異なるためです。したがって、送信者と受信者の間の相互運用性は、各プロトコル要素に対して妥当な長さが何であるかについての共有された期待に依存します。さらに、一部のプロトコル要素に対して一般的に理解されている妥当な長さは、過去30年間のHTTP使用の過程で変化しており、将来も変化し続けると予想されます。
少なくとも、受信者は、他のメッセージでそれらと同じプロトコル要素に対して生成する値と少なくとも同じ長さのプロトコル要素の長さを解析および処理できなければなりません (MUST)。たとえば、自身のリソースへの非常に長いURI参照を公開する起点サーバーは、ターゲットURIとして受信したときにそれらと同じ参照を解析および処理できる必要があります。
多くの受信されたプロトコル要素は、その要素を識別して下流に転送するために必要な範囲でのみ解析されます。たとえば、仲介者は、受信したフィールドをそのフィールド名とフィールド値コンポーネントに解析する場合がありますが、フィールド値内でさらに解析せずにそのフィールドを転送します。
2.4. Error Handling (エラー処理)
受信者は、受信したプロトコル要素を、本仕様 (本仕様の拡張を含む) によって定義されたセマンティクスに従って解釈しなければなりません (MUST)。ただし、受信者が (経験または構成を通じて) 送信者がそれらのセマンティクスによって暗示されるものを誤って実装していると判断した場合を除きます。たとえば、User-Agentヘッダーフィールドの検査が、特定のコンテンツコーディングの受信時に失敗することが知られている特定の実装バージョンを示している場合、起点サーバーは受信したAccept-Encodingヘッダーフィールドの内容を無視する場合があります。
特に記載がない限り、受信者は無効な構造から使用可能なプロトコル要素を回復しようと試みてもよい (MAY) です。HTTPは、セキュリティに直接影響を与える場合を除き、特定のエラー処理メカニズムを定義していません。これは、プロトコルのさまざまなアプリケーションが異なるエラー処理戦略を必要とするためです。たとえば、Webブラウザは、LocationヘッダーフィールドがABNFに従って解析されない応答から透過的に回復することを望む場合がありますが、システム制御クライアントは、あらゆる形式のエラー回復を危険と見なす場合があります。
セクション9.2.2で説明されているように、基礎となる接続障害が発生した場合、クライアントは一部のリクエストを自動的に再試行できます。
2.5. Protocol Version (プロトコルバージョン)
HTTPのバージョン番号は、"." (ピリオドまたは小数点) で区切られた2つの10進数で構成されます。最初の数字 (メジャーバージョン、Major Version) はメッセージング構文を示し、2番目の数字 (マイナーバージョン、Minor Version) は、送信者がそのメジャーバージョン内で適合している最高のマイナーバージョン (将来の通信のために理解できる) を示します。
HTTPのコアセマンティクスはプロトコルバージョン間で変更されませんが、「ワイヤー上」での表現は変更される可能性があるため、ワイヤー形式に互換性のない変更が加えられると、HTTPバージョン番号が変更されます。さらに、HTTPは、定義された拡張ポイント (セクション16) を使用することにより、バージョンを変更せずにプロトコルに段階的で後方互換性のある変更を加えることができます。
プロトコルバージョン全体は、そのバージョンの対応する仕様で定められた一連の要件に対する送信者の適合性を示します。たとえば、バージョン「HTTP/1.1」は、この文書、「HTTP Caching」[CACHING]、および「HTTP/1.1」[HTTP/1.1] の組み合わせ仕様によって定義されます。
HTTPのメジャーバージョン番号は、互換性のないメッセージ構文が導入されたときに増分されます。マイナー番号は、プロトコルに加えられた変更がメッセージセマンティクスに追加されるか、送信者の追加機能を暗示する効果がある場合に増分されます。
マイナーバージョンは、送信者がプロトコルの後方互換性のあるサブセットのみを使用している場合でも、送信者の通信機能を通知します。これにより、受信者は、より高度な機能を応答 (サーバーによる) または将来のリクエスト (クライアントによる) で使用できることを知ることができます。