4. HTTPにおける識別子

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

4.1. URI参照

URI参照は、リクエストのターゲット指定、リダイレクトの指示、および関係の定義に使用されます。

"URI-reference"、"absolute-URI"、"relative-part"、"authority"、"port"、"host"、"path-abempty"、"segment"、および"query"の定義は、URI汎用構文から採用されています。空でないパスコンポーネントを含むことができるプロトコル要素のために、"absolute-path"ルールが定義されています。(このルールは、空のパスを許可するRFC 3986のpath-abemptyルール、および"//"で始まるパスを許可しないpath-absoluteルールとは若干異なります。) 相対URIを含むことができるがフラグメントコンポーネントを含まないプロトコル要素のために、"partial-URI"ルールが定義されています。

URI-reference = <URI-reference, see [URI], Section 4.1>
absolute-URI  = <absolute-URI, see [URI], Section 4.3>
relative-part = <relative-part, see [URI], Section 4.2>
authority     = <authority, see [URI], Section 3.2>
uri-host      = <host, see [URI], Section 3.2.2>
port          = <port, see [URI], Section 3.2.3>
path-abempty  = <path-abempty, see [URI], Section 3.3>
segment       = <segment, see [URI], Section 3.3>
query         = <query, see [URI], Section 3.4>

absolute-path = 1*( "/" segment )
partial-URI   = relative-part [ "?" query ]

HTTPでURI参照を許可する各プロトコル要素は、そのABNF生成規則において、要素がどの形式の参照を許可するか (URI-reference)、絶対形式のURIのみ (absolute-URI)、パスとオプションのクエリコンポーネントのみ (partial-URI)、または上記の組み合わせを示します。特に明記されていない限り、URI参照はターゲットURI (セクション7.1) に対して相対的に解析されます。

すべての送信者と受信者は、プロトコル要素において最低8000オクテットの長さのURIをサポートすることが推奨されます (RECOMMENDED)。これは、いくつかの構造およびワイヤ表現 (例えば、HTTP/1.1のリクエスト行) が、場合によっては必然的により大きくなることを意味することに注意してください。

4.2. HTTP関連のURIスキーム

IANAは、https://www.iana.org/assignments/uri-schemes/でURIスキームのレジストリ [BCP35] を管理しています。リクエストは任意のURIスキームをターゲットにする可能性がありますが、以下のスキームはHTTPサーバーに固有のものです:

URIスキーム	説明	セクション
http	ハイパーテキスト転送プロトコル	4.2.1
https	ハイパーテキスト転送プロトコルセキュア	4.2.2

表 2

"http"または"https" URIの存在は、識別されたオリジンに常にHTTPサーバーが接続を待ち受けていることを意味するものではないことに注意してください。サーバーが存在するかどうか、またはそのサーバーが現在その識別子をリソースにマッピングしているかどうかに関係なく、誰でもURIを作成できます。登録名とIPアドレスの委譲された性質は、HTTPサーバーが存在するかどうかに関係なく、連合された名前空間を作成します。

4.2.1. http URIスキーム

"http" URIスキームは、指定されたポートでTCP ([TCP]) 接続を待ち受ける潜在的なHTTPオリジンサーバーによって管理される階層的名前空間内で識別子を作成するために、ここで定義されます。

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

"http" URIのオリジンサーバーは、authorityコンポーネントによって識別されます。これには、ホスト識別子 ([URI]、セクション3.2.2) とオプションのポート番号 ([URI]、セクション3.2.3) が含まれます。ポートサブコンポーネントが空または指定されていない場合、TCPポート80 (WWWサービスの予約ポート) がデフォルトです。オリジンは、セクション4.3.2で定義されているように、識別されたリソースをターゲットとするリクエストに対して権威的に応答する権利を誰が持つかを決定します。

送信者は、空のホスト識別子を持つ"http" URIを生成してはなりません (MUST NOT)。そのようなURI参照を処理する受信者は、それを無効として拒否しなければなりません (MUST)。

階層的パスコンポーネントとオプションのクエリコンポーネントは、そのオリジンサーバーの名前空間内のターゲットリソースを識別します。

4.2.2. https URIスキーム

"https" URIスキームは、指定されたポートでTCP接続を待ち受け、HTTP通信のために保護されたTLS ([TLS13]) 接続を確立できる潜在的なオリジンサーバーによって管理される階層的名前空間内で識別子を作成するために、ここで定義されます。この文脈において、"保護された" (secured) とは、具体的には、サーバーが識別された権威を代表して行動するものとして認証されており、そのサーバーとのすべてのHTTP通信が、クライアントとサーバーの両方にとって受け入れ可能な機密性と完全性保護を持つことを意味します。

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

"https" URIのオリジンサーバーは、authorityコンポーネントによって識別されます。これには、ホスト識別子 ([URI]、セクション3.2.2) とオプションのポート番号 ([URI]、セクション3.2.3) が含まれます。ポートサブコンポーネントが空または指定されていない場合、TCPポート443 (HTTP over TLSの予約ポート) がデフォルトです。オリジンは、セクション4.3.3で定義されているように、識別されたリソースをターゲットとするリクエストに対して権威的に応答する権利を誰が持つかを決定します。

送信者は、空のホスト識別子を持つ"https" URIを生成してはなりません (MUST NOT)。そのようなURI参照を処理する受信者は、それを無効として拒否しなければなりません (MUST)。

階層的パスコンポーネントとオプションのクエリコンポーネントは、そのオリジンサーバーの名前空間内のターゲットリソースを識別します。

クライアントは、"https"リソースに対するHTTPリクエストが、通信される前に保護されていること、およびそれらのリクエストに対する保護された応答のみを受け入れることを確認しなければなりません (MUST)。クライアントとサーバーにとって受け入れ可能な暗号化メカニズムの定義は、通常交渉され、時間とともに変化する可能性があることに注意してください。

"https"スキームを介して利用可能になるリソースは、"http"スキームと共有されたアイデンティティを持ちません。それらは、別々の名前空間を持つ異なるオリジンです。ただし、Cookie プロトコル [COOKIE] など、同じホストを持つすべてのオリジンに適用されると定義されているHTTPへの拡張は、1つのサービスによって設定された情報が、一致するホストドメインのグループ内の他のサービスとの通信に影響を与えることを許可します。このような拡張は、保護された接続から取得された情報が、保護されていないコンテキスト内で誤って交換されることを防ぐために、細心の注意を払って設計されるべきです。

4.2.3. http(s)の正規化と比較

"http"または"https"スキームを持つURIは、[URI] のセクション6で定義されている方法に従って、各スキームについて上記で説明されたデフォルトを使用して正規化および比較されます。

HTTPは、等価性を決定するための特定の方法の使用を要求しません。たとえば、キャッシュキーは、構文ベースの正規化後、またはスキームベースの正規化後に、単純な文字列として比較される場合があります。

"http"および"https" URIのスキームベースの正規化 ([URI] のセクション6.2.3) には、以下の追加ルールが含まれます:

• ポートがスキームのデフォルトポートと等しい場合、正規形式はポートサブコンポーネントを省略することです。

• OPTIONSリクエストのターゲットとして使用されていない場合、空のパスコンポーネントは"/"の絶対パスと同等であるため、正規形式は空のパスの代わりに"/"のパスを提供することです。

• スキームとホストは大文字と小文字を区別せず、通常は小文字で提供されます; 他のすべてのコンポーネントは大文字と小文字を区別する方法で比較されます。

• "reserved"セット以外の文字は、パーセントエンコードされたオクテットと同等です: 正規形式はそれらをエンコードしないことです ([URI] のセクション2.1および2.2を参照)。

たとえば、以下の3つのURIは同等です:

http://example.com:80/~smith/home.html
http://EXAMPLE.com/%7Esmith/home.html
http://EXAMPLE.com:/%7esmith/home.html

正規化後 (任意の方法を使用) に同等である2つのHTTP URIは、同じリソースを識別すると仮定でき、任意のHTTPコンポーネントは正規化を実行してもよいです (MAY)。その結果、異なるリソースは、正規化後に同等であるHTTP URIによって識別されるべきではありません (SHOULD NOT) ([URI] のセクション6.2で定義されている任意の方法を使用)。

4.2.4. http(s) URIにおけるuserinfoの非推奨化

authorityのURI汎用構文には、URI内にユーザー認証情報を含めるためのuserinfoサブコンポーネント ([URI]、セクション3.2.1) も含まれています。そのサブコンポーネントにおいて、"user:password"形式の使用は非推奨です。

一部の実装は、コマンド呼び出しオプション、構成ファイル、またはブックマークリスト内など、認証情報の内部構成にuserinfoコンポーネントを使用しますが、そのような使用はユーザー識別子またはパスワードを露出する可能性があります。

送信者は、"http"または"https" URI参照がメッセージ内でターゲットURIまたはフィールド値として生成される場合、userinfoサブコンポーネント (およびその"@"デリミタ) を生成してはなりません (MUST NOT)。

信頼できないソースから受信した"http"または"https" URI参照を使用する前に、受信者はuserinfoを解析し、その存在をエラーとして扱うべきです (SHOULD); それはフィッシング攻撃のために権威を曖昧にするために使用されている可能性があります。

4.2.5. フラグメント識別子を持つhttp(s)参照

フラグメント識別子は、[URI] のセクション3.5で定義されているように、URIスキームに依存せずに二次リソースを間接的に識別することを許可します。URIを参照する一部のプロトコル要素は、フラグメントの包含を許可しますが、他は許可しません。それらは、フラグメントが許可される要素のABNFルールの使用によって区別されます; そうでなければ、フラグメントを除外する特定のルールが使用されます。

注: フラグメント識別子コンポーネントは、URIスキームのスキーム定義の一部ではありません ([URI] のセクション4.3を参照)。したがって、上記の"http"および"https" URIスキームのABNF定義には現れません。

4.3. 権威的アクセス

権威的アクセスとは、クライアントが権威的である (リソース所有者によって制御されている) と信じる方法で、識別されたリソースへのアクセスのために、与えられた識別子を逆参照することを指します。アクセスが許可されるかどうかを決定するプロセスは、URIスキームによって定義され、汎用構文が使用される場合のauthorityコンポーネントなど、URIコンポーネント内のデータを使用することがよくあります。ただし、権威的アクセスは、識別されたメカニズムに限定されません。

セクション4.3.1は、そのような用途の補助としてオリジンの概念を定義し、後続のサブセクションは、ピアがオリジンを代表する権限を持つことを確立する方法を説明します。

権威の確立に関連するセキュリティの考慮事項については、セクション17.1を参照してください。

4.3.1. URIオリジン

与えられたURIの"オリジン" (origin) は、スキームとホストを小文字に正規化し、ポートを正規化して先頭のゼロを削除した後の、スキーム、ホスト、およびポートの三つ組です。URIからポートが省略されている場合、そのスキームのデフォルトポートが使用されます。たとえば、URI

https://Example.Com/happy.js

は、オリジン

{ "https", "example.com", "443" }

を持ちます。

これは、ポートが常に存在する正規化されたURIプレフィックスとしても記述できます:

https://example.com:443

各オリジンは、独自の名前空間を定義し、その名前空間内の識別子がリソースにどのようにマッピングされるかを制御します。逆に、オリジンが時間の経過とともに一貫して有効なリクエストにどのように応答するかが、ユーザーがURIに関連付けるセマンティクスを決定し、それらのセマンティクスの有用性が最終的にこれらのメカニズムを、ユーザーが将来参照およびアクセスするためのリソースに変換します。

2つのオリジンは、スキーム、ホスト、またはポートが異なる場合、異なります。同じエンティティが2つの異なるオリジンを制御していることを検証できる場合でも、それらのオリジン下の2つの名前空間は、そのオリジンに対して権威的なサーバーによって明示的にエイリアスされない限り、異なります。

オリジンは、[RFC6454] で説明されているように、このドキュメントの範囲を超えて、HTML および関連するWebプロトコル内でも使用されます。

4.3.2. httpオリジン

HTTPはトランスポートプロトコルから独立していますが、"http"スキーム (セクション4.2.1) は、authorityコンポーネント内で識別されたホストの指定されたポートでTCP接続を待ち受けるオリジンサーバーを制御する誰とでも権威を関連付けることに特化しています。これは、クライアント固有の名前解決メカニズムと、経路上の攻撃者から保護されていない可能性がある通信の両方に依存するため、非常に弱い意味での権威です。それにもかかわらず、信頼された環境内での一貫した解決のために"http"識別子をオリジンサーバーにバインドするための十分な最小値です。

ホスト識別子がIPアドレスとして提供される場合、オリジンサーバーは、そのIPアドレスの指定されたTCPポートのリスナー (もしあれば) です。ホストが登録名の場合、登録名は、適切なオリジンサーバーのアドレスを見つけるために、DNSなどの名前解決サービスで使用される間接識別子です。

"http" URIが、指示されたリソースへのアクセスを要求するコンテキスト内で使用される場合、クライアントは、ホスト識別子をIPアドレスに解決し、指定されたポートでそのアドレスへのTCP接続を確立し、その接続を介して、クライアントのターゲットURIと一致するリクエストターゲットを含むHTTPリクエストメッセージを送信することによって、アクセスを試みてもよいです (MAY) (セクション7.1)。

サーバーがセクション15で説明されているように、非暫定的なHTTP応答メッセージでそのようなリクエストに応答する場合、その応答はクライアントのリクエストに対する権威的な答えと見なされます。

ただし、上記は権威的な応答を取得するための唯一の手段ではなく、権威的な応答が常に必要であることを意味するものでもないことに注意してください ([CACHING] を参照)。たとえば、Alt-Svcヘッダーフィールド [ALTSVC] は、オリジンサーバーがそのオリジンに対しても権威的な他のサービスを識別することを許可します。"http"で識別されたリソースへのアクセスは、このドキュメントの範囲外のプロトコルによっても提供される可能性があります。

4.3.3. httpsオリジン

"https"スキーム (セクション4.2.2) は、クライアントが識別されたオリジンサーバーに対して信頼できると考える証明書に対応する秘密鍵を使用するサーバーの能力に基づいて権威を関連付けます。クライアントは通常、証明書を信頼できると考えるために、事前に手配または構成された何らかのトラストアンカーから伝達される信頼の連鎖に依存します (セクション4.3.4)。

HTTP/1.1およびそれ以前では、クライアントは、そのURIオリジンのホストに対して特別に行われた、正常に確立され保護された接続を介して通信する場合にのみ、サーバーに権威を帰属させます。接続の確立と証明書の検証は、権威の証明として使用されました。

HTTP/2およびHTTP/3では、URIオリジンのホストがサーバー証明書に存在する任意のホストと一致し、クライアントがそのURIに対してそのホストへの接続を開くことができると信じている場合、クライアントは、正常に確立され保護された接続を介して通信する際にサーバーに権威を帰属させます。実際には、クライアントは、オリジンのホストが確立された接続と同じサーバーIPアドレスを含むかどうかを確認するためにDNSクエリを実行します。オリジンサーバーは、同等のORIGINフレーム [RFC8336] を送信することによって、この制限を削除できます。

リクエストターゲットのホストとポートの値は、各HTTPリクエストで渡され、オリジンを識別し、同じサーバーによって制御される可能性がある他の名前空間とそれを区別します (セクション7.2)。オリジンは、その証明書の秘密鍵への制御を提供する任意のサービスが、対応する"https"名前空間の管理に対しても同様に責任があること、または少なくとも誤った方向に向けられているように見えるリクエストを拒否する準備ができていることを確認する責任があります (セクション7.4)。

オリジンサーバーは、それに対して権威的である場合でも、特定のターゲットURIのリクエストを処理することを望まない可能性があります。たとえば、ホストが異なるポート (例えば、443対8000) で異なるサービスを実行している場合、オリジンサーバーでターゲットURIをチェックすることが必要です (接続が保護された後でも)、なぜならネットワーク攻撃者が1つのポートの接続を他のポートで受信させる可能性があるためです。ターゲットURIのチェックに失敗すると、そのような攻撃者が、1つのターゲットURI (例えば、"https://example.com/foo") への応答を、別のポートからの一見権威的な応答 (例えば、"https://example.com:8000/foo") で置き換えることを許可する可能性があります。

"https"スキームは、権威の関連付けにTCPおよび接続されたポート番号に依存しないことに注意してください。なぜなら、両方とも保護された通信の外側にあり、したがって決定的なものとして信頼できないからです。したがって、HTTP通信は、セクション4.2.2で定義されているように、TCPを使用しないプロトコルを含む、任意の保護されたチャネルを介して行われる可能性があります。

"https" URIが、指示されたリソースへのアクセスを要求するコンテキスト内で使用される場合、クライアントは、ホスト識別子をIPアドレスに解決し、指定されたポートでそのアドレスへのTCP接続を確立し、機密性と完整性保護を持つTCPを介してTLSを正常に開始することによって接続をエンドツーエンドで保護し、その接続を介して、クライアントのターゲットURIと一致するリクエストターゲットを含むHTTPリクエストメッセージを送信することによって、アクセスを試みてもよいです (MAY) (セクション7.1)。

サーバーがセクション15で説明されているように、非暫定的なHTTP応答メッセージでそのようなリクエストに応答する場合、その応答はクライアントのリクエストに対する権威的な答えと見なされます。

ただし、上記は権威的な応答を取得するための唯一の手段ではなく、権威的な応答が常に必要であることを意味するものでもないことに注意してください ([CACHING] を参照)。

4.3.4. https証明書の検証

URIを逆参照するために保護された接続を確立するには、クライアントは、サービスのアイデンティティがURIのオリジンサーバーに対して受け入れ可能な一致であることを検証しなければなりません (MUST)。証明書の検証は、経路上の攻撃者または名前解決を制御する攻撃者によるサーバーのなりすましを防ぐために使用されます。このプロセスでは、クライアントが一連のトラストアンカーで構成されている必要があります。

通常、クライアントは、サービスアイデンティティを検証するために、[RFC6125] のセクション6で定義されている検証プロセスを使用しなければなりません (MUST)。クライアントは、サービスのホストから参照アイデンティティを構築しなければなりません (MUST): ホストがリテラルIPアドレス (セクション4.3.5) である場合、参照アイデンティティはIP-IDであり、そうでなければホストは名前であり、参照アイデンティティはDNS-IDです。

クライアントは、CN-IDタイプの参照アイデンティティを使用してはなりません (MUST NOT)。[RFC6125] のセクション6.2.1で述べられているように、CN-IDタイプの参照アイデンティティは、古いクライアントによって使用される可能性があります。

クライアントは、代替形式のサーバーアイデンティティ検証を受け入れるように特別に構成される可能性があります。たとえば、クライアントは、アドレスとホスト名が動的であるサーバーに接続し、ターゲットURIのオリジンと一致するものではなく、特定の証明書 (または何らかの外部で定義された参照アイデンティティと一致する証明書) をサービスが提示することを期待している可能性があります。

特殊なケースでは、クライアントが単にサーバーのアイデンティティを無視することが適切である可能性がありますが、これは接続を能動的攻撃に対して開かれたままにすることを理解する必要があります。

証明書がターゲットURIのオリジンに対して有効でない場合、ユーザーエージェントは、継続する前にユーザーから確認を取得する (セクション3.5を参照) か、不正な証明書エラーで接続を終了しなければなりません (MUST)。自動化されたクライアントは、エラーを適切な監査ログに記録しなければならず (MUST) (利用可能な場合)、不正な証明書エラーで接続を終了すべきです (SHOULD)。自動化されたクライアントは、このチェックを無効にする構成設定を提供してもよいですが (MAY)、それを有効にする設定を提供しなければなりません (MUST)。

4.3.5. IP-ID参照アイデンティティ

"https" URIの"host"フィールドでIPアドレスリテラルによって識別されるサーバーは、IP-IDタイプの参照アイデンティティを持ちます。IPバージョン4アドレスは"IPv4address" ABNFルールを使用し、IPバージョン6アドレスは"IPv6address"オプションを持つ"IP-literal"生成規則を使用します; [URI] のセクション3.2.2を参照してください。IP-IDの参照アイデンティティには、IPアドレスのデコードされたバイトが含まれます。

IPバージョン4アドレスは4オクテット、IPバージョン6アドレスは16オクテットです。IP-IDの使用は、他のIPバージョンに対して定義されていません。証明書のsubjectAltName拡張のiPAddress選択は、IPバージョンを明示的に含まず、代わりにアドレスの長さに依存してバージョンを区別します; [RFC5280] のセクション4.2.1.6を参照してください。

IP-IDタイプの参照アイデンティティは、アドレスが証明書のsubjectAltName拡張のiPAddress値と同一である場合に一致します。