target URL

要求対象 (HTTP)

[8048] 要求対象 (request target) は、要求メッセージ要求行に指定される、 要求の適用対象を表す文字列です。要求対象は、対象URL の一部を表しています。

[8049] RFC 2616 までは Request-URI と呼ばれていました。

仕様書

対象資源と対象URL

[8018] HTTP 通信を行う利用者エージェントの目的は、 要求意味 (semantics) と、その意味が適用される対象資源 (target resource) の組み合わせです >>8017

[8019] 対象資源は普通対象URI (target URI) によって識別されます。 対象URIは、素片識別子を含みません。 >>8017

[8050] 対象URLは直接要求メッセージには現れず、要求対象として記述されます。 要求対象その他 HTTP 要求メッセージに現れる情報などから復元した要求対象であったと考えられる URL のことを、実効要求URLといいます。

利用者エージェントにおいては実効要求URLとは対象URLであると定義されています。

要求対象

[8022] 要求対象 (request target) 要求メッセージ対象資源を表すもので、 要求行に含まれます。

[8021] 要求対象は、要求行に記述します。

[8023] 要求対象には次に示す4つの形式があります >>8020

  1. |
    1. origin-form
    2. absolute-form
    3. authority-form
    4. asterisk-form
[16] RFC 2616 世代までは要求URL (request URL) (request-URI) と呼ばれていましたが、 URL でない * も含まれるためか、 RFC 723x 世代で要求対象に改められています。
method
要求メソッド
origin
origin-form
absolute
absolute-form
authority
authority-form
asterisk
asterisk-form
method
CONNECT
authority
MUST
absolute
×
asterisk
×
origin
×
method
OPTIONS (サーバー全体)
asterisk
起源サーバーへの要求
absolute
プロキシへの要求
origin
×
authority
×
method
OPTIONS (その他)
origin
起源サーバーへの要求
absolute
プロキシへの要求
authority
×
asterisk
×
method
その他
origin
起源サーバーへの要求
absolute
プロキシへの要求
authority
×
asterisk
×

[21] HTTP/2 では要求行がなく、かわりに疑似ヘッダーを使います。 HTTP/1.1 以下要求対象とおおむね対応する用法が規定されていますが、 :schemeorigin-form 相当と asterisk-form 相当で必須となっており、 :authorityasterisk-form 相当で必須となっている点は異なります。

[31] ダイジェスト認証では response="" 引数rspauth="" 引数の計算にも使います。

[32] ダイジェスト認証では uri="" 引数にも要求URLを指定します。

origin-form

[8028] origin-form は、 絶対パスか、 または絶対パスのあとに ?query が続くものです >>8020 5.3.1.

  1. 絶対パス
  2. ?
    1. ?
    2. query
[8029] 素片識別子は認められていません。
[8032] ホストポートHost: によって指定します。

[8030] クライアントは、 CONNECT全体に対する OPTIONS要求の場合を除き、 起源鯖に直接要求するときには、 origin-form要求対象として指定しなければなりません >>8020 5.3.1.

[8031] 対象URLパスの時は、 / を送らなければなりません >>8020 5.3.1.

[17] HTTP/2 では、擬似ヘッダー :path:scheme を指定し :authority を指定しない (Host: ヘッダーを指定する) 形に相当するようです。 HTTP/1.1 以下要求プロキシHTTP/2 に変換して転送する場合に現れます。

absolute-form

[8033] absolute-form は、 RFC 3986 absolute-URI です >>8020 5.3.2.

  1. URL scheme
  2. :
  3. ?
    1. //
    2. authority
  4. path
  5. ?
    1. ?
    2. query
[8034] 素片は認められていません。
[33] 構文上 userinfo は禁止されていませんが、あまり適切では無さそうです。

[8035] クライアントは、 CONNECT全体に対する OPTIONS要求の場合を除き、 要求するときには、 absolute-form要求対象として指定しなければなりません >>8020 5.3.2.

[8036] HTTP/1.1 クライアントに対する要求でしかこの形を使いませんが、 はこの形の要求を受け入れなければなりません >>8020 5.3.2.

[8037] 将来のHTTPの版ですべての要求absolute-form に移行できるようにするため >>8020 5.3.2. と説明されています。
[8038] Host: と両方指定されたときはどう処理されるのでしょうか。 → Host: 参照。 Host: が無視されます。 なお Host: はそれでも必ず指定しなければなりません。

[8043] 要求鎖の最後のは、 OPTIONS 要求absolute-form で受信した時は、 パスが空で query がなければ、 起源鯖転送する際に要求対象* に変更して送信しなければなりません >>8020 5.3.4.

[8] 古い HTTP/1.0 は、絶対URLでの要求404 応答を返すことがあります。

[18] HTTP/2 では疑似ヘッダーとして :scheme:authority:path を指定する形に相当します。ほとんどの HTTP/2 要求はこの形を使います。

authority-form

[8039] authority-form は、 RFC 3986 authority です >>8020 5.3.3.

  1. ホスト
  2. ?
    1. :
    2. ポート

[8040] クライアントは、 CONNECT メソッドによってトンネルを確立するときは、 対象URLauthority (userinfo@ 以外) のみを送信しなければなりません >>8020 5.3.3.

[19] HTTP/2 では疑似ヘッダー :authority を指定し、 :scheme:path を指定しない形に相当します。 CONNECT 要求でのみ使われます。

[34] ポートが省略された場合にどう解釈するべきかはあまり明確ではありません。 常に 80 とみなすべきでしょうか。

実効要求URLも参照。

asterisk-form

[8041] asterisk-form は、文字 * です >>8020 5.3.4.

  1. *

[8042] クライアントは、OPTIONS 要求全体に対して行いたいときは、 * を送らなければなりません >>8020 5.3.4.

[15] SSDP要求メソッド NOTIFY, M-SEARCH でも要求URLには * を使います >>14

[20] HTTP/2 では疑似ヘッダー :scheme:authority を指定し、 :path* と指定する形が相当します。

長さ

[503] 実際上要求行の長さには色々な制限が課されていますが、 最低でも8000オクテット要求行には対応するべきである >>8016 とされています。 (要求行には要求対象の他にメソッドHTTPの版も含まれています。)

[502] 構文解析したい URI の長さを超える要求対象を受信したは、 414 を返さなければなりません >>8016

構文解析とエラー処理

[8011] Request-URIURL schemeauthority が含まれている場合で、それがその起源鯖が提供している資源URL schemeauthority でないとき、 400 応答を返すのが良さそうです。

[8012] RFC には authority が正しくない時に 400 を返すと規定があります。 URL scheme については言及がありません。

[22] 要求対象// から始まるとき、 Apachenginx も、 absolute-form と解釈するようです。

authority から始まる相対URLとは解釈しません。
[23] 非ASCII文字が含まれるとき、

[24] nginxabsolute-formorigin-form でないとき、要求行を受け取った時点で HTTP/0.9 応答 (400 相当の HTML文書) を返すようです。

書き換え

[8045] は、要求対象ホスト名FQDN でないなら、 自身のドメインを追加してから転送して構いません >>8044FQDN なら変更してはなりません >>8044

[8046] Host:転送時に再生成することになっていますので、 そちらも書き換わります。

[8047] は、他の規定による場合を除き、転送時に要求対象絶対パスquery を書き換えてはなりません >>8044

[9] パーセント符号化の正規化なども認められていないようです。

[25] ダイジェスト認証では、要求対象プロキシに書き換えられる可能性があるとして、 credentialsuri="" 引数にも実効要求URL を指定できるとしています。

URL の起源

[26] 対象URLは、普通はそのサーバー起源同じ起源です。

[28] HTTP/2 では、異なる起源であっても、IPアドレス証明書が同じHTTP接続を再利用できることになっています。

HTTP接続の再利用の項を参照。

[27] プロキシの場合、いろいろな起源要求を受信することになります。 FTP over HTTPGopher over HTTP のように、異なる URL scheme が使われることもあります。

[29] サーバー起源サーバーとして動作するかプロキシとして動作するかは、 サーバーの設定によって決まります。クライアントがどちらのつもりで接続するかも、 クライアントの設定によって決まります。どちらであるかは、 プロトコルの動作には明確には反映されません。どんなサーバーも、 任意の要求URLを受け取る可能性があり、クライアントはそれを禁止されていません。

[30] 意味があるかどうかは別として、 mailto:data: のような URL要求URLとなることもあります。

[35] Opportunistic Security for HTTP/2 の場合、 HTTPS 上の要求であるにも関わらず :schemehttp となります。

歴史

[8024] RFC 1945 (HTTP/1.0); RFC 2068・2616 (HTTP/1.1) 5.1.2 Request-URI

The Request-URI is a Uniform Resource Identifier (Section section 3.2) and identifies the resource upon which to apply the request.

Request-URI は統一資源識別子で、 要求を適用する資源を識別します。

  • {1945:} Request-URI = absoluteURI | abs_path
  • {2068:} Request-URI = "*" | absoluteURI | abs_path
  • {2616:} Request-URI = "*" | absoluteURI | abs_path | authority
  • {Errata:} Request-URI = "*" | absoluteURI | abs_path [ "?" query ] | authority

The two three four options for Request-URI are dependent on the nature of the request. The asterisk "*" means that the request does not apply to a particular resource, but to the server itself, and is only allowed when the method used does not necessarily apply to a resource. One example would be

Request-URI の4つの選択肢は要求の性質に依存します。星印 * は、要求が特定の資源に適用するのではなく、サーバー自体に適用することを意味し、方式が必ずしも資源に適用する必要が無いときにだけ認めます。一つの例は

{2068,2616}

  • OPTIONS * HTTP/1.1

The absoluteURI form is only allowed required when the request is being made to a proxy. The proxy is {1945} requested {2068} required {2616} REQUIRED to forward the request or service it from a valid cache, and return the response. If the request is GET or HEAD and a prior response is cached, the proxy may use the cached message if it passes any restrictions in the Expires header field. Note that the proxy may MAY forward the request on to another proxy or directly to the server specified by the absoluteURI. In order to avoid request loops, a proxy must MUST be able to recognize all of its server names, including any aliases, local variations, and the numeric IP address. An example Request-Line would be:

absoluteURI (絶対 URI) 書式は、に対して要求を行う時にだけ認めますは必須です。 串は要求を転送するかまたは妥当キャッシュから供出して応答を返す必要があります要求が GET または HEAD で、前の応答がキャッシュされているときは、 Expires 頭欄の制限を満たしていれば、串はそのキャッシュしたメッセージを使っても構いません。 串は要求を他の串に転送しても構いませんabsoluteURI で指定されたサーバーに直接転送しても構わないことに注意してください。 要求の循環を避けるため、串は別名, 局所変名, 数値 IP 番地を含めたすべてのサーバー名を認識することができなければなりませんRequest-Line の例:

  • GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.0
  • GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1

To allow for transition to absoluteURIs in all requests in future versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.

将来の版の HTTP ですべての要求を absoluteURI に移行することができるように、すべての HTTP/1.1 サーバーは要求中の absoluteURI 形式を受け入れなければなりません。 たとえ HTTP/1.1 クライアントが串に対する要求でのみそれを生成するとしてもです。

The authority form is only used by the CONNECT method (section 9.9).

authority 書式は CONNECT 方式でのみ使用します。

The most common form of Request-URI is that used to identify a resource on an origin server or gateway. In this case, only the absolute path of the URI is MUST be transmitted (see Section section 3.2.1, abs_path) as the Request-URI, and the network location of the URI (net_loc authority) MUST be transmitted in a Host header field. For example, a client wishing to retrieve the resource above directly from the origin server would create a TCP connection to port 80 of the host "www.w3.org" and send the lines:

Request-URI の最も広く行われている書式は、 起源サーバーまたは関門資源を識別するのに使います。 この場合、 URI の絶対経路のみRequest-URI として転送しなければなりませんで、 URI のネットワーク部分 (authority) は Host 頭欄で転送しなければなりません

  • GET /pub/WWW/TheProject.html HTTP/1.0
  • GET /pub/WWW/TheProject.html HTTP/1.1
    Host: www.w3.org

followed by the remainder of the Full-Request. Note that the absolute path cannot be empty; if none is present in the original URI, it must MUST be given as "/" (the server root).

に要求の残りが続きます。 絶対経路は空になり得ないことに注意してください。元の URI になにもないときには / (サーバー根) を与えなければなりません

{2068} If a proxy receives a request without any path in the Request-URI and the method specified is capable of supporting the asterisk form of request, then the last proxy on the request chain MUST forward the request with "*" as the final Request-URI. For example, the request

串が経路のない Request-URI の要求を受信し、指定されていたメソッドが星印書式の要求に対応することのできるものであるなら、 要求鎖の最後の串は * を最後の Request-URI として要求を転送しなければなりません。 例えば、要求

  • OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1

would be forwarded by the proxy as

はホスト www.ics.uci.edu のポート 8001 に接続した後、串によって転送されて

  • OPTIONS * HTTP/1.1
    Host: www.ics.uci.edu:8001

after connecting to port 8001 of host "www.ics.uci.edu".

となります。

{1945,2068} The Request-URI is transmitted as an encoded string, where some characters may be escaped using the "% HEX HEX" encoding defined by RFC 1738 [4] in the format specified in section 3.2.1. {2616} If the Request-URI is encoded using the "% HEX HEX" encoding [42], the {1945,2068} The origin server must {2068,2616} MUST decode the Request-URI in order to properly interpret the request. {2068,2616} Servers SHOULD respond to invalid Request-URIs with an appropriate status code.

Request-URI% HEX HEX 符号化を使って符号化されている場合には、 起源サーバーは要求を適切に解釈するために Request-URI を復号しなければなりません。 サーバーは不当な Request-URI に対して適当な状態符号で応答するべきです

{2068,2616} In requests that they forward, proxies A transparent proxy MUST NOT rewrite the "abs_path" part of a the received Request-URI when forwarding it to the next inbound server, in any way except as noted above to replace a null abs_path with "*", no matter what the proxy does in its internal implementation.

;次の上りサーバーに転送する要求中では、透過串は、上で触れた null abs_path* で置換する場合を除いて、 (その内部実装で串が何をしていようと、) 受信した Request-URI 中の abs_path 部分を書き換えてはなりません

{2068,2616} Note: The "no rewrite" rule prevents the proxy from changing the meaning of the request when the origin server is improperly using a non-reserved {1945,2068} URL URI character for a reserved purpose. Implementers should be aware that some pre-HTTP/1.1 proxies have been known to rewrite the Request-URI.

注意: 「書き換えしない」規則によって、起源サーバーが非予約 URI 文字を不適切に予約目的に使っているときに串が要求の意味を変えてしまうことを防ぎます。 実装者は、 HTTP/1.1 以前の串で Request-URI を書き換えるものがあると分かっていることに注意するべきです。

注: 注記なき修正は 1945→2068 の変更点。

[8025] RFC 2068・2616 (HTTP/1.1) 5.2 The Resource Identified by a Request

HTTP/1.1 origin servers SHOULD be aware that the The exact resource identified by an Internet request is determined by examining both the Request-URI and the Host header field.

インターネット要求で識別される正確な資源は Request-URIHost 頭欄の両方の検査で決定します。

An origin server that does not allow resources to differ by the requested host MAY ignore the Host header field value when determining the resource identified by an HTTP/1.1 request. (But see section 19.5.1 19.6.1.1 for other requirements on Host support in HTTP/1.1.)

要求されたホストによって資源を変えることを認めない起源サーバーは、HTTP/1.1 要求により識別される資源を決定する時に Host 頭欄値を無視しても構いません。 (しかし HTTP/1.1 での Host 対応の他の要件について 19.6.1.1 節を参照。)

An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or vanity host names) MUST use the following rules for determining the requested resource on an HTTP/1.1 request:

要求されたホストによって資源を区別する起源サーバー (時たま仮想ホストとか変化ホスト名とか言われます。) は、 HTTP/1.1 要求の要求している資源を決定するのに次の規則を使わなければなりません

  1. 1. If Request-URI is an absoluteURI, the host is part of the Request-URI. Any Host header field value in the request MUST be ignored.
  2. 2. If the Request-URI is not an absoluteURI, and the request includes a Host header field, the host is determined by the Host header field value.
  3. 3. If the host as determined by rule 1 or 2 is not a valid host on the server, the response MUST be a 400 (Bad Request) error message.
  1. Request-URIabsoluteURI なら、 ホストは absoluteURI の一部。 要求中の Host 頭欄値は無視しなければなりません
  2. Request-URIabsoluteURI でなく、要求が Host 頭欄を含んでいれば、 ホストは Host 頭欄値で決定します。
  3. 規則 1・2 で決定したホストがそのサーバーで妥当なホストでなければ、 応答は 400 (悪い要求) 誤りメッセージでなければなりません

Recipients of an HTTP/1.0 request that lacks a Host header field MAY attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to determine what exact resource is being requested.

Host 頭欄を欠いた HTTP/1.0 要求の受信者は、 どの資源が要求されているのかを決定するために発見的方法 (例えば特定ホストに固有の URI 経路を検査するとか) を使うことを試みても構いません

[8026]

[5] HTTP で素片識別子を送ってくる糞ロボットもたまにいます。 (名無しさん 2004-03-16 07:53:34 +00:00)

[6] >>5 ロボットだけじゃなくて WinIE 6.0 だったりするから藁えん。 (名無しさん 2004-05-17 12:39:12 +00:00)

[7] >>5-6 素片識別子つきで送ってくる困った UA は古今絶えたことのないのでございますが、 それに対応していない鯖は素片識別子をちゃんと捨てないので利用者からすればまったく困ったこととなってしまいます。 (本来鯖としては別にあえて対応する必要もないのですけど、人に優しく自分に厳しくの原則からして、対応しておいても悪くないでしょう。)

ちょっと古いですけど、実際に問題になった例: CyberDogの不具合 http://mtlab.ecn.fpu.ac.jp/WSM_1996/960823202241.html

[8002] WinIE は (いつもなのか条件付なのか知りませんが) IRI百分率符号化せずに Request-URI に使って送ってきます。

[8027] RFC 2326 (RTSP) 6.2 Request Header Fields
  request-header  =          Accept                   ; Section 12.1
                  |          Accept-Encoding          ; Section 12.2
                  |          Accept-Language          ; Section 12.3
                  |          Authorization            ; Section 12.5
                  |          From                     ; Section 12.20
                  |          If-Modified-Since        ; Section 12.23
                  |          Range                    ; Section 12.29
                  |          Referer                  ; Section 12.30
                  |          User-Agent               ; Section 12.41

Note that in contrast to HTTP/1.1 [2], RTSP requests always contain the absolute URL (that is, including the scheme, host and port) rather than just the absolute path.

[1] HTTP/1.1 とは異なり、 RTSP 要求は常に絶対経路だけではなくて絶対 URL を (つまり、 scheme, host, port を含めて) 指定することに注意して下さい。

HTTP/1.1 requires servers to understand the absolute URL, but clients are supposed to use the Host request header. This is purely needed for backward-compatibility with HTTP/1.0 servers, a consideration that does not apply to RTSP.

[2] HTTP/1.1 はサーバーが絶対 URL を理解することを要求していますが、 クライアントは Host 頭を使うことを想定しています。 これは単に HTTP/1.0 サーバーとの後方互換性からの必要であって、 RTSP では考慮する必要はないのです。

The asterisk "*" in the Request-URI means that the request does not apply to a particular resource, but to the server itself, and is only allowed when the method used does not necessarily apply to a resource. One example would be:

[3] Request-URI での星印 * は、要求が特定の資源には適用されるのではなく、 サーバー自体に適用され、使用している method が必ずしも資源に適用される物ではない時にのみ認められます。 一つの例を次に示します。

OPTIONS * RTSP/1.0

S-HTTP

[12] S-HTTP では常に * とすることとなっていました >>13

実際の要求URLカプセル化されたHTTPメッセージ側に指定することとなっていました。

RFC 2109、RFC 2965 における定義

[8003] RFC 2109RFC 2965 におけるrequest-URI は、クライアント要求行の一部として送る absoluteURI のうちの abs_path の部分です。 >>8004, >>8005

[8007] 関連して request-host という用語があります。

[8006] つまり、RFC 2109RFC 2965 における request-URIURLpath の部分だけ (schemehostquery は含まない) ということですね。

HSTS

[8014]

Request URI
is the URI used to cause a UA to issue an HTTP request message. See also "Effective Request URI".

OData

[11] ODataapplication/http に含まれる要求URL について、 HTTP 仕様上認められているものの他、 (その application/http より外側のURL基底URLとする) 相対URLを指定することを認めています >>10

関連

[8009] Digest認証で使われる uri 引数には request-URI と同じ値を指定することになっています。

[8013] CGI には REQUEST_URI メタ変数 (環境変数) があります。

[8051] 要求対象の定義には含まれませんが、 Max-Forwards: ヘッダーも暗示的、間接的に要求が適用される対象を指定するものとなっています。

メモ

[8052] [tech]HTTP GETメソッドのURIの長さ制限を調べてみた - Kazumi007の日記 ( ( 版)) http://d.hatena.ne.jp/Kazumi007/20090921/1253501500

[36] AWS ALBに長いリクエストURLでGETすると414や500でエラーになる - YOMON8.NET () http://yomon.hatenablog.com/entry/2017/08/25/012347

[37] Configuration • Akka HTTP () https://doc.akka.io/docs/akka-http/current/configuration.html

# Sets the strictness mode for parsing request target URIs.

# The following values are defined:

#

# `strict`: RFC3986-compliant URIs are required,

# a 400 response is triggered on violations

#

# `relaxed`: all visible 7-Bit ASCII chars are allowed

#

uri-parsing-mode = strict

[38] Editorial: url ➡️ URL (annevk著, ) https://github.com/whatwg/fetch/commit/5088fce32b79bd0b22047d30869581f8b7e79be8