[8048] 要求対象は、要求メッセージの要求行に指定される、 要求の適用対象を表す文字列です。要求対象は、対象URL の一部を表しています。
[8018] HTTP 通信を行う利用者エージェントの目的は、 要求の意味と、その意味が適用される対象資源の組み合わせです >>8017。
[8019] 対象資源は普通対象URIによって識別されます。 対象URIは、素片識別子を含みません。 >>8017
[8050] 対象URLは直接要求メッセージには現れず、要求対象として記述されます。 要求対象その他 HTTP 要求メッセージに現れる情報などから復元した要求の対象であったと考えられる URL のことを、実効要求URLといいます。
[8022] 要求対象は要求メッセージの対象資源を表すもので、 要求行に含まれます。
[8023] 要求対象には次に示す4つの形式があります >>8020。
要求メソッド | origin-form | absolute-form | authority-form | asterisk-form |
---|---|---|---|---|
CONNECT | × | × | MUST | × |
OPTIONS (サーバー全体) | × | プロキシへの要求 | × | 起源サーバーへの要求 |
OPTIONS (その他) | 起源サーバーへの要求 | プロキシへの要求 | × | × |
その他 | 起源サーバーへの要求 | プロキシへの要求 | × | × |
[21] HTTP/2 では要求行がなく、かわりに疑似ヘッダーを使います。
HTTP/1.1 以下の要求対象とおおむね対応する用法が規定されていますが、
:scheme
は origin-form
相当と
asterisk-form
相当で必須となっており、
:authority
は asterisk-form
相当で必須となっている点は異なります。
[31] ダイジェスト認証では response=""
引数や
rspauth=""
引数の計算にも使います。
origin-form
#✎[8028] origin-form
は、
絶対パスか、
または絶対パスのあとに ?
と query
が続くものです
>>8020 5.3.1.。
[8030] クライアントは、 CONNECT
や鯖全体に対する
OPTIONS
の要求の場合を除き、
起源鯖に直接要求するときには、
origin-form
を要求対象として指定しなければなりません
>>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.。
[8035] クライアントは、 CONNECT
や鯖全体に対する
OPTIONS
の要求の場合を除き、
串に要求するときには、
absolute-form
を要求対象として指定しなければなりません
>>8020 5.3.2.。
[8036] HTTP/1.1 クライアントは串に対する要求でしかこの形を使いませんが、 鯖はこの形の要求を受け入れなければなりません >>8020 5.3.2.。
[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.。
[8040] クライアントは、 CONNECT
メソッドによってトンネルを確立するときは、
対象URLの authority (userinfo と @
以外)
のみを送信しなければなりません >>8020 5.3.3.。
[19] HTTP/2 では疑似ヘッダー :authority
を指定し、 :scheme
と :path
を指定しない形に相当します。 CONNECT
要求でのみ使われます。
[34] ポートが省略された場合にどう解釈するべきかはあまり明確ではありません。 常に 80 とみなすべきでしょうか。
asterisk-form
#✎[8041] asterisk-form
は、文字
*
です >>8020 5.3.4.。
[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-URI に URL scheme や authority が含まれている場合で、それがその起源鯖が提供している資源の
URL scheme と authority でないとき、 400
応答を返すのが良さそうです。
[22] 要求対象が //
から始まるとき、 Apache も nginx も、
absolute-form
と解釈するようです。
[24] nginx は absolute-form
や origin-form
でないとき、要求行を受け取った時点で HTTP/0.9 応答
(400
相当の HTML文書) を返すようです。
[8045] 串は、要求対象のホスト名が FQDN でないなら、 自身のドメインを追加してから転送して構いません >>8044。 FQDN なら変更してはなりません >>8044。
[8047] 串は、他の規定による場合を除き、転送時に要求対象の絶対パスや
query
を書き換えてはなりません >>8044。
[25] ダイジェスト認証では、要求対象がプロキシに書き換えられる可能性があるとして、
credentials の uri=""
引数にも実効要求URL
を指定できるとしています。
[26] 対象URLは、普通はそのサーバーの起源と同じ起源です。
[28] HTTP/2 では、異なる起源であっても、IPアドレスと証明書が同じHTTP接続を再利用できることになっています。
[27] プロキシの場合、いろいろな起源の要求を受信することになります。 FTP over HTTP や Gopher over HTTP のように、異なる URL scheme が使われることもあります。
[29] サーバーが起源サーバーとして動作するかプロキシとして動作するかは、 サーバーの設定によって決まります。クライアントがどちらのつもりで接続するかも、 クライアントの設定によって決まります。どちらであるかは、 プロトコルの動作には明確には反映されません。どんなサーバーも、 任意の要求URLを受け取る可能性があり、クライアントはそれを禁止されていません。
[35] Opportunistic Security for HTTP/2 の場合、
HTTPS 上の要求であるにも関わらず :scheme
が http
となります。
The Request-URI is a Uniform Resource Identifier (
Sectionsection 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
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 betwothree
Request-URI
の4つの選択肢は要求の性質に依存します。星印 *
は、要求が特定の資源に適用するのではなく、サーバー自体に適用することを意味し、方式が必ずしも資源に適用する必要が無いときにだけ認めます。一つの例は
{2068,2616}
- OPTIONS * HTTP/1.1
The absoluteURI form is
only allowedrequired when the request is being made to a proxy. The proxy is{2616} REQUIRED to forward the request or service it from a valid cache, and return the response.{1945} requested{2068} requiredIf 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 proxymayMAY forward the request on to another proxy or directly to the server specified by the absoluteURI. In order to avoid request loops, a proxymustMUST 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.0GET 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
, onlythe absolute path of the URIisMUST be transmitted (seeSectionsection 3.2.1, abs_path) as the Request-URI, and the network location of the URI (net_locauthority) 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, itmustMUST 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{2616} If the Request-URI is encoded using the "% HEX HEX" encoding [42], theas 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.{1945,2068} Theorigin servermust{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, proxiesA transparent proxy MUST NOT rewrite the "abs_path" part ofathe received Request-URI when forwarding it to the next inbound server,in any wayexcept 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} URLURI 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 の変更点。
HTTP/1.1 origin servers SHOULD be aware that theThe exact resource identified by an Internet request is determined by examining both the Request-URI and the Host header field.
インターネット要求で識別される正確な資源は Request-URI
と Host
頭欄の両方の検査で決定します。
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.119.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. 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. 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. 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.
Request-URI
が absoluteURI
なら、
ホストは absoluteURI
の一部。
要求中の Host
頭欄値は無視しなければなりません。Request-URI
が absoluteURI
でなく、要求が Host
頭欄を含んでいれば、
ホストは Host
頭欄値で決定します。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 経路を検査するとか)
を使うことを試みても構いません。
[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
に使って送ってきます。
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
[8003] RFC 2109、RFC 2965 におけるrequest-URI
は、クライアントが鯖に要求行の一部として送る absoluteURI
のうちの abs_path
の部分です。 >>8004, >>8005
[8006] つまり、RFC 2109、RFC 2965 における request-URI は URL の path の部分だけ (scheme や host や query は含まない) ということですね。
- Request URI
- is the URI used to cause a UA to issue an HTTP request message. See also "Effective Request URI".
[11] OData は application/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
# 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
Request-URI
と呼ばれていました。