[1] Location:
ヘッダーは、リダイレクト先の
URL を指定するものです。
[450] Location:
ヘッダーは通常 3xx
状態符号と共に利用します。利用者エージェントはリダイレクトの応答を受け取ると、
自動的に Location:
で指定された URL
に改めて要求を送信します。
[425] Location:
ヘッダーは、応答に関係ある資源を参照するものです。
その関係は要求メソッドと状態符号の意味の組み合わせにより決まります。 >>424
[426] Location:
ヘッダーの値は、 RFC 3986
URI参照です。 >>424
[435] 素片識別子が適切で無い場面もあるとして、
201
を例に挙げています >>424 が、
なぜか禁止はされていません。また 201
以外にも不適切な場面が存在することを暗示していますが、
実際に何が該当するのかは不明です。
[417] 起源鯖は、 POST
要求の処理に成功して1つ以上の資源が作られた時には、
201
応答を送信するべきです。
Location:
ヘッダーに作成された主たる資源の URL
を含めるべきです。表現は要求の状態と新しい資源への参照を説明したものとするべきです。
>>412
[449] 鯖が 300
応答において好ましい選択肢を有する時は、
その URL を含む Location:
を生成するべきです >>448。
[442] 鯖は、 301
/308
応答に Location:
ヘッダーを生成して新しい永続的
URL の好ましい URL を指定するべきです >>441, >>2。
[444] 鯖は、 302
応答や
307
応答に別の URL を含む
Location:
ヘッダーを生成するべきです >>443, >>447。
[446] 鯖は、 303
応答では Location:
ヘッダーでリダイレクト先の URL を指定します >>445。
[420] 起源鯖は、 POST
要求の処理の結果が既存の資源の表現と等価である時には、
その URL を Location:
ヘッダーに指定した
303
応答を送信することができます >>412。
201
と 3xx
以外での Location:
の使用は禁止されていませんし、
その解釈も規定されていません。また 304
でも禁止されていませんし、
どう解釈するべきかも不明です。[6] OData は 202
応答でも Location:
ヘッダーを使っています。その場合指定された URL は処理対象の最新の状態を取得できる
URL とされています >>4。
[427] 相対URLが指定されている場合の基底URLは、 実効要求URLです >>424。
[436] Location:
ヘッダーに妥当な RFC 3986
URI参照以外が指定された時に回復しようとする受信者もありますが、
RFC 7231 はそのような処理を強制も定義もしない、しかししても良い >>424
とされています。
[437] 現実には RFC 3986 URI参照でない URL を Location:
ヘッダーに指定する鯖 (Webアプリケーションなど) は多々存在します。
利用者エージェントがWeb互換であるためには、ヘッダーの値を
UTF-8 により復号し、その結果を URL Standard
に従い解決する必要があると思われます。
[422] 利用者エージェントは、
300
301
, 302
, 303
,
307
, 308
または未対応の 3xx
の状態符号の応答に
Location:
があれば、
自動的にリダイレクトして構いません >>448, >>441, >>443, >>421, >>445, >>447, >>2。
[26] 利用者エージェントは、それ以外の応答で Location:
が指定されていても自動的にリダイレクトしてはいけません。
[451] リダイレクトの処理については、 HTTPリダイレクトの項を参照してください。
Location:
ヘッダー#✎[314] CGI では Location:
欄は CGI欄であり、CGIスクリプトがCGI応答に指定したものを鯖が解釈します。
[23] >>20 サーバー内 redirect を何度も繰り返し行うことも出来ます。 (HTTP Server は無限 loop にならないように対策する必要があるでしょう。)
[29] CGI で Location:
を使う時は、
Content-Type: 欄は不要なら出力しなくて構いません。
例えば、
print <<EOH; Location: http://foo.example/bar(改行) (改行) EOH
というだけの出力の CGI script では Content-Type: text/html とか出力しなくてもいいです。 (というかむしろ書いたら、1文字もない「空」では HTML として成立しませんから不適当な指定となります。)
[34] CGI 欄は折り畳みが認められていないことにも注意が必要です。つまり
Location: http://foo.example/
は HTTP では可能ですが、 CGI では不正です。 (まあ URI が値のこの欄ではしないとは思いますけどね。)
... のいずれかの値を指定できます。前者の場合はクライアント・リダイレクト応答となり、
そのままHTTP Location:
欄となります。後者の場合は局所リダイレクト応答となり、
鯖が指定された path (と query) で要求を受け取ったものとして再処理します。
>>313
[316] 両者の場合それぞれで、他の頭欄や応答本体の有無、それを受け取った鯖の処理が異なります。 詳しくはそれぞれの項をご参照ください。
location
要素 (WebDAV)#✎[24] 207
応答に含まれる個別の状態符号が
3xx
である場合、鯖は HTTP Location:
ヘッダーのかわりに location
要素を使わなければなりません >>9, >>37。
201
の場合にも使えます >>37。
[25] 内容は、要素内容であり、 href
要素1つです >>37。 href
要素の内容が
Location:
ヘッダーの値に相当します
>>37。
[39] response
要素の子要素として使うことができます >>38。
[36] クライアントは、 location
要素が指定されることに依存してはなりません。
指定されなかった場合には、個別の資源に要求してリダイレクト先の URL
を得られないか試しても構いません。 >>9
[317] WWW-Talk Jan-Mar 1994: Re: Redirection: "Location" or "Uri" ? ( ( 版)) http://1997.webhistory.org/www.lists/www-talk.1994q1/0216.html
The Location response-header field
defines the exact location of the resource that was identified by the Request-URIis used to redirect the recipient to a location other than the Request-URI for completion of the request or identification of a new resource. For 201 (Created) responses, the Location is that of the new resource which was created by the request.For 3xx responses, the location
mustSHOULD indicate the server's preferred{1945,2068} URL{2616} URI for automatic redirection to the resource.Only one absolute URL is allowed.The field value consists of a single absolute{1945,2068} URL{2616} URI.
[5] Location
応答頭欄は、要求の完了又は新しい資源の特定のために
Request-URI 以外の場所に受信者を再指向するのに使います。
201 (Created: 作成。) 応答では、 Location
は要求により作られた新しい資源の場所です。
3xx 要求では、この場所は、資源への自動誘導のための、サーバー側的により好ましい
URI を示します。
欄の値は単一の絶対 URI で構成します。
- Location = "Location" ":" absoluteURI {Errata} [ "#" fragment ]
訳注: Errata の件について HTTPリダイレクト (>>35) を参照。
An example is: {2616}
例:
Location: http://www.w3.org/hypertext/WWW/NewLocation.html- Location: http://www.w3.org/pub/WWW/People.html
Note: The Content-Location header field (section
14.1514.14) differs from Location in that the Content-Location identifies the original location of the entity enclosed in the request. It is therefore possible for a response to contain header fields for both Location and Content-Location. Also see section 13.10 for cache requirements of some methods.
[8] 注意: Content-Location
頭欄は Location
とは異なり、要求に同封された実体の場所を識別します。
従って、応答に Location
と
Content-Location
の双方を含めることも可能です。
幾つかの方式のキャッシュ要求について、 13.10
節も参照。
注: 注記のない修正は、 RFC 1945→2068 での変更箇所。
At least one CGI-Field MUST be supplied, but no CGI field name may be used more than once in a response. If a body is supplied, then a "Content-type" header field MUST be supplied by the script, otherwise the script MUST send a "Location" or "Status" header field. If a Location CGI-Field is returned, then the script MUST NOT supply any HTTP-Fields.
[33] 最低1つの CGI 欄を供給しなければなりません。
但し同じ CGI 欄名を1つの応答中に複数使ってはいけません。
本体を供給する場合、 script は「Content-type」
頭欄を供給しなければなりません。
そうでない場合 (本体を供給しない場合) script は
は「Location」頭欄か「Status」頭欄を送らなければなりません。
Location
CGI 欄を返す場合、 script はどの HTTP
欄も供給してはいけません。
This is used to specify to the server that the script is returning a reference to a document rather than an actual document.
[10] これは、サーバーに対してスクリプトが実際の文書ではなく文書への参照を返すことを指定するのに使います。
The Location value is either an absolute URI with optional fragment, as defined in RFC 1630 [1], or an absolute path within the server's URI space (i.e., omitting the scheme and network-related fields) and optional query-string. If an absolute URI is returned by the script, then the server MUST generate a '302 redirect' HTTP response message unless the script has supplied an explicit Status response header field. Scripts returning an absolute URI MAY choose to provide a message-body. Servers MUST make any appropriate modifications to the script's output to ensure the response to the user-agent complies with the response protocol version. If the Location value is a path, then the server MUST generate the response that it would have produced in response to a request containing the URL
-[21] scheme "://" SERVER_NAME ":" SERVER_PORT rel-URL-abs-path
[20] Location
値は、 RFC1630 で定義されている絶対
URI 及び省略可能な断片か、又はサーバーの URI
空間内の絶対経路 (すなわち、scheme とネットワーク関連欄を省略したもの。)
及び省略可能な query-string のいずれかです。
絶対 URI が script により返された場合、サーバーは、
Status
応答頭欄が明示的に指定されていない限り、
「302 redirect」 HTTP 応答メッセージを生成しなければなりません。
絶対 URI を返す script は message-body
を提供することを選んでも構いません。
サーバーは、利用者エージェントへの応答が応答のプロトコルの版に合致することを確実にするため、
script の出力を適当に修正しなければなりません。
Location 値が経路である場合、サーバーは >>21 の URL
を含む要求への応答であるとして応答を生成しなければなりません。
Note: If the request was accompanied by a message-body (such as for a POST request), and the script redirects the request with a Location field, the message-body may not be available to the resource that is the target of the redirect.
[22] 注意: 要求が message-body
を伴っていて (POST 要求の場合など)、
script が要求を Location
欄で redirect
した場合、 redirect の対象の資源には message-body
は利用可能でないかもしれません。
[45] 噂によると tok2 では広告の関係で CGI header Location:
が使えないらしいです。
[46] >>45 トクトクは CGI 使えますと宣伝していましたよね。本当だとしたら虚偽広告ということになります。やめていただきたいね。
[28] サーバーによっては Cookie と相性が悪いようです。 (CGIでクッキーセットした後にLocationで他のURLに飛ばしたいんですが・・・ http://tohoho.wakusei.ne.jp/lng/199908/99080130.htm) ((200
の HTML 文書以外では Cookie は使わない方が良いですね。色々の実装状況的に。))
[50] >>28 これ、 Location
と Set-Cookie
を併用すると
IIS 3.0 や PWS では上手くいかない、 Apache
では上手くいく、ということですけど、こんなことってあり得ますかね?
Redirect 前と redirect 後の扱いで UA 側で不具合 (あるいは仕様)
によって上手くいかない可能性は大いにあると思うのですけど、
それならどのサーバーでも上手くいかないはずです。 Location
あるいは 3xx
使用時に Set-Cookie
を捨てるような設計に IIS がなっているとすればこの挙動になるのでしょうけど、
そんな設計するような根拠が思いつかない。
もっとも、 >>28 のやりとりは話してる内容が大雑把過ぎて何ともいえませんよね。 誰かがちゃんと確かめた方がいいと思いますけど、今時 IIS なんて使ってる人いますか?
[59]
修正パッチなしのなつみかんにはContent-Location:
欄
(などLocation
が含まれる頭欄をLocation:
欄と誤認する不具合があります。
ねこめしにっき(2006年1月) http://www.remus.dti.ne.jp/~a-satomi/nikki/2006/01a.html?01090700#d08n01
(名無しさん 2006-01-09 08:22:59 +00:00)
Content-Type: text/html; charset=iso-8859-1 Location: http://foo.example/bar/
と言われて、 http://foo.example/bar/ を取り寄せると
Content-Type: text/html
であって中身が日本語の漢字かな混じり文とかの時に、文字コード自動判別が行われずにそのまま ISO-8859-1 と認識され、文字化けするという問題が起きました。
[31] この問題で一番悪いのは、 ISO-8859-1 以外の文書に charsetパラメーターを付けずに送り出す相手サーバーです。
Apache 1.3.12 で >>30 の上の例のように、エラー・メッセージで必ず
charset
パラメーターをつけるように修正された
(安全性の問題への対処のため。) ことで、正しい charset
パラメーターを HTML
文書につけて送らない日本語文書が主のサーバーで広範囲で問題が起こりました。
問題の直接的な原因となった 1.3.12 の修正を元に戻すことで対策を行ったところやそれを薦める人もいましたが、それは間違っています。
[55] きっとこの問題って、リンク先の頁もきっとリンク元の頁と同じ
charset
であることが多いだろうなあ、
利用者のために補完したるか、っていう親切心で実装したんでしょうねぇ。
だとしたら Netscape の開発者を責めるのは可哀想かもしれない。
もちろん責められるべきは charset
引数の値を正しく設定できないサーバー管理者のあなたです。20世紀にはそれが許されましたが、21世紀には許されませんよ。
[56] Location:
欄に不正な文字列を指定したとします。
例えば、
Location: http://invalid%3A80/
を含む redirect 応答を返したとします。
[57] このとき、 WinIE6 では、 サーバーに接続できませんという画面になりますが、 そのアドレス棒の URI は redirect 前のものになったままです。 飛ぼうとした redirect 先 URI は画面のどこにも出てきません。
つまり、 redirect 元の鯖には正しく接続できて応答ももらっているくせに、 その応答がいかれているがために、 その鯖にすら接続できなかったかのような紛らわしいメッセージが表示されてしまうのです。
[454] HTTPリダイレクトを参照してください。
[318] #185 (Location header payload handling) – httpbis ( ( 版)) http://trac.tools.ietf.org/wg/httpbis/trac/ticket/185
[329] draft-ietf-httpbis-p2-semantics-22 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content ( ( 版)) http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-22#section-7.1.2
[455] しかし RFC 723x でも未解決の問題がいくつも指摘されています。
[411] RFC 7252 - The Constrained Application Protocol (CoAP) ( ( 版)) http://tools.ietf.org/html/rfc7252#section-5.10.7
[43] Google BigQuery は 200
で Location:
を使っています >>42。
Request-URI
Content-Location:
欄201 (Created)
3xx
[32] w3m の LocalCGI 機能で似たようなものとして
w3m-Control:
欄 + GOTO
があります。
w3m-control: GOTO file:///cgi-bin/foo.cgi のように使います。
[7] SSDP の LOCATION:
ヘッダーとは意味が異なります。
[44] WWW-Talk Jan-Mar 1994: Re: Redirection: "Location" or "Uri" ? ( 版) http://1997.webhistory.org/www.lists/www-talk.1994q1/0221.html
If (and when), the subscription is denied, the hub MUST inform the subscriber by sending an HTTP [RFC2616] GET request to the subscriber's callback URL as given in the subscription request.
Hubs may provide an additional HTTP [RFC2616] Location header (as described in section 14.30 of Hypertext Transfer Protocol [RFC2616]) to indicate that the subscriber may retry subscribing to a different hub.topic. This allows for limited distribution to specific groups or users in the context of social web applications.
[48] Kolejny XSS w www.google.com (Custom Search Engine) ( 版) http://sekurak.pl/kolejny-xss-w-www-google-com-custom-search-engine/
[51] Fix #111: forbid redirects to data URLs · whatwg/fetch@f986c43 ( 版) https://github.com/whatwg/fetch/commit/f986c43f958a0f7ffdc46553d5a53a0c56a89a32
[52] 655389 – CRLF Injection and the parsing of HTTP headers ( 版) https://bugzilla.mozilla.org/show_bug.cgi?id=655389
[53] Merge URLUtils into Location · whatwg/html@f0a7365 ( 版) https://github.com/whatwg/html/commit/f0a73659b4046cc35a28855f3544dead66345689
[54] Defining exotic objects in IDL, HTML, or both? (Anne van Kesteren 著, 版) https://lists.w3.org/Archives/Public/www-archive/2015Oct/0009.html
[58] annevk/html-cross-origin-objects ( 版) https://github.com/annevk/html-cross-origin-objects
[60] 1142083 – IDN Unicode domain redirect is broken in Firefox 36/37/38 ( 版) https://bugzilla.mozilla.org/show_bug.cgi?id=1142083
[61] >>60 http://zymiausifotografai.lt/
HTTP/1.1 301 Moved Permanently Date: Fri, 06 Nov 2015 09:15:23 GMT Server: Apache Location: http://www.žymiausifotografai.lt Vary: Accept-Encoding Content-Length: 312 Connection: close Content-Type: text/html; charset=iso-8859-1
[62] Add some more parameters to the "perform a security check" hook (for … · heycam/webidl@adf3772 ( 版) https://github.com/heycam/webidl/commit/adf37720bd92138f9f1627a214330287550c0004
[63] 29383 – Need a way to define toJSON, valueOf, @@toPrimitive ( 版) https://www.w3.org/Bugs/Public/show_bug.cgi?id=29383
[64] 27361 – [Unforgeable] and "[[Enumerable]]: true" ( 版) https://www.w3.org/Bugs/Public/show_bug.cgi?id=27361
[65] 29183 – Objects that implement an [Unforgeable] interface should have a non-configurable @@toPrimitive method ( 版) https://www.w3.org/Bugs/Public/show_bug.cgi?id=29183
[66] annevk/html-cross-origin-objects ( 版) https://github.com/annevk/html-cross-origin-objects
[67] URLs are parsed and produce records · whatwg/html@30bc255 ( 版) https://github.com/whatwg/html/commit/30bc2557105ad62881ec9670f253febbc9761b44
[68] Fix #212: redirects parse Location headers against the response's url · whatwg/fetch@a8c5f4d ( 版) https://github.com/whatwg/fetch/commit/a8c5f4d0fc712573383873e1d7a4aa3a2ad9c392
[69] Acknowledge Bobby Holley for Window/Location security design · whatwg/html@20f97a2 ( 版) https://github.com/whatwg/html/commit/20f97a2aebfff007d56f6310d6d5caa96b98329d
[70] Define security around Window, WindowProxy, and Location properly · whatwg/html@acae3df ( 版) https://github.com/whatwg/html/commit/acae3df652b382e9f4f1d1b4dc7e08e2b00df821
[71] Give response a location URL for reuse in HTML (annevk著, ) https://github.com/whatwg/fetch/commit/8d922d9178cbcab296ca3b3a76a775949e3a87a8
[72] Editorial: cleanup prior commit (annevk著, ) https://github.com/whatwg/fetch/commit/2db24f3d97fc57c14eb133d3a41ecdc55409aa00
[73] Navigate: remove "gone async" and define redirect handling (annevk著, ) https://github.com/whatwg/html/commit/8b630f5e4fa2ec8b0999470d09490bffe6e9a1e3
[74] 22654 – Duplicate Location headers () https://www.w3.org/Bugs/Public/show_bug.cgi?id=22654
[75] Preventing some CRLF header injection attacks · Issue #375 · whatwg/fetch () https://github.com/whatwg/fetch/issues/375
Returning HTTP 202 Created and a Location header when creating a post
When the post is created, the Micropub endpoint must return either an HTTP 201 Created status code or HTTP 202 Accepted code, and must return a Location header indicating the URL of the created post. [RFC2616]
After double checking, it could be confirmed that SVN was affected in the worst way: SVN follows HTTP 301 redirects to svn+ssh:// URLs. As a result, an innocent looking HTTP URL can be used to trigger a Command Execution with a 301 redirect.
[79] RFC 4437 - Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Resources () https://tools.ietf.org/html/rfc4437#section-5
[80] Editorial: replace UTF-8 encode with isomorphic encode (annevk著, ) https://github.com/whatwg/fetch/commit/ffbaefb5c4f68b9d619e9db6491fd665a30a2ffb
[81] Editorial: replace UTF-8 encode with isomorphic encode by annevk · Pull Request #742 · whatwg/fetch () https://github.com/whatwg/fetch/pull/742
[82] Request-URIのパスからのオープンリダイレクト · GitHub () https://gist.github.com/atsunoda/5c6e7a4ab35e7cbda2cdd4b292d9a573
3xx
ではLocation:
を受信した利用者エージェントは自動的にリダイレクトすることが期待されていますが、201
では自動的なリダイレクトは期待されておらず、 単にリンクが示されるだけです。本来なら両者は別のヘッダーとするべきだったでしょう。 (201
はLink:
の方が適切だったでしょう。)