実効要求 URL (HTTP)

[3] HTTP における実効要求URL (effective request URL) は、 HTTP 要求メッセージから復元した要求されている URL です。

仕様書

[4] 鯖では、実効要求URL (effective request URL) は次のように決定します。

[21] HSTS と RFC 7230 では、実質的な定義は同じですが、定義方法が微妙に異なっています。特に RFC 7230 は、鯖の設定を用いることが認められています。この違いが意図的なのか、それとも出版時期の違いによるものなのかはわかりません。

[10] HSTS では、 Host: がない場合は未定義 >>2 とされていました。

[11] HSTS では、 authority-form の場合、実効要求URLは未定義 >>2 とされていました。この形を使うのは CONNECT の時なので、 HSTS では実効要求URL を定義する必要がありませんでした。

[13] HTTP/1.1 仕様に従わない要求については定義も言及もされていません。例えば非ASCII文字が含まれる場合は定義されていません。

[27] RFC 7230 によればそのような場合 400 を返すことになっていますから、問題ではないと考えているのかもしれません。しかし現実にはそのような要求を送信するクライアントがありますから、適当にパーセント符号化されていたと解釈するべきかもしれません。

[34] 素片識別子が含まれている場合の扱いも不明です。

[35] 同じく、素片識別子を送信するクライアントがありますから、適宜無視するべきだと思われます。

[28] HTTP over Unixドメインソケットのように、適当な URL scheme が存在せず実効要求URLが決められないこともあります。

[14] 比較は、 RFC 2616 の定義によるとされています >>2 (HTTPにおけるURLの比較を参照)。ただし path が無い URL と / は異なるものとして扱わなければなりません >>2。

[36] absolute-form も参照。

[29] クライアントは要求対象や Host: に任意の値を指定できますから、鯖はこれが適切な値かどうか検査する必要があります。

要求対象、Host: も参照。

[32] TLS を用いている場合、 SNI に指定された値と実効要求URL の値が一致しているか確認する必要があります。

SNI も参照。

[30] この検査を怠ると、 DNS rebinding 攻撃その他の脆弱性につながることがありますし、鯖やアプリケーションの設計や実装方法次第で認証をすり抜けるなどの不具合が生じる場合もあり、危険です。

[31] セキュリティー上の問題以外でも、同一の資源を表す URL が複数になり参照する人や場面によって異なる URL になって不便が生じることもあります。