[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
[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
[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
[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:
の方が適切だったでしょう。)