DAV:location

Location: ヘッダー (HTTP)

[1] Location: ヘッダーは、リダイレクト先の URL を指定するものです。

[450] Location: ヘッダーは通常 3xx 状態符号と共に利用します。利用者エージェントリダイレクト応答を受け取ると、 自動的に Location: で指定された URL に改めて要求を送信します。

C
利用者エージェント
S
起源鯖
S2
起源鯖'
C -> S
要求
S -> C
3xx Location: URL
C -> S2
URL要求
S2 -> C
応答

仕様書

意味

[425] Location: ヘッダーは、応答に関係ある資源を参照するものです。 その関係は要求メソッド状態符号の意味の組み合わせにより決まります。 >>424

[431] 201 応答では、要求によって作成された主たる資源を指します >>424

[432] 3xx 応答では、自動的なリダイレクト好ましい (preferred) とされる対象資源を指します >>424

[433] 3xx では Location: を受信した利用者エージェントは自動的にリダイレクトすることが期待されていますが、 201 では自動的なリダイレクトは期待されておらず、 単にリンクが示されるだけです。本来なら両者は別のヘッダーとするべきだったでしょう。 (201Link: の方が適切だったでしょう。)
[438] Content-Location:応答に含まれる表現URL とされており、どちらの意味の Location: とも異なるものです >>424

構文

[426] Location: ヘッダーの値は、 RFC 3986 URI参照です。 >>424

  1. ASCII URL
[428] HTTPヘッダーでは非ASCII文字は認められていません。
[430] 絶対URLでも相対URLでも構いません。空文字列である相対URLも使えます。 過去には仕様上相対URLを認めていなかった時代もありましたが、 実情に合わせて現在は認められています。
[429] 素片識別子も使うことができます。

[435] 素片識別子が適切で無い場面もあるとして、 201 を例に挙げています >>424 が、 なぜか禁止はされていません。また 201 以外にも不適切な場面が存在することを暗示していますが、 実際に何が該当するのかは不明です。

文脈

[417] 起源鯖は、 POST 要求の処理に成功して1つ以上の資源が作られた時には、 201 応答を送信するべきですLocation: ヘッダーに作成された主たる資源URL を含めるべきです表現要求の状態と新しい資源への参照を説明したものとするべきです>>412

[449] 300 応答において好ましい (prefer) 選択肢を有する時は、 その 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 要求の処理の結果が既存の資源表現と等価である時には、 その URLLocation: ヘッダーに指定した 303 応答を送信することができます >>412

[440] なぜか仕様上 2013xx 以外での Location: の使用は禁止されていませんし、 その解釈も規定されていません。また 304 でも禁止されていませんし、 どう解釈するべきかも不明です。

[6] OData202 応答でも Location: ヘッダーを使っています。その場合指定された URL は処理対象の最新の状態を取得できる URL とされています >>4

[27] Location: ヘッダーを複数指定することはできません。

処理

[427] 相対URLが指定されている場合の基底URLは、 実効要求URLです >>424

[436] Location: ヘッダーに妥当な RFC 3986 URI参照以外が指定された時に回復しようとする受信者もありますが、 RFC 7231 はそのような処理を強制も定義もしない、しかししても良い >>424 とされています。

[437] 現実には RFC 3986 URI参照でない URLLocation: ヘッダーに指定する (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リダイレクトの項を参照してください。

無限のリダイレクト素片識別子HTTP 以外のプロトコルへのリダイレクトfetch/navigate/レンダリングとの関係などについてなどはHTTPリダイレクトの項を参照してください。

[3] Location: の値はキャッシュにおける非妥当化に使われることもあります。

[41] 207 応答については、 207 も参照。

CGI における 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 が値のこの欄ではしないとは思いますけどね。)

[315] CGILocation: 欄では

... のいずれかの値を指定できます。前者の場合はクライアント・リダイレクト応答となり、 そのままHTTP Location: 欄となります。後者の場合は局所リダイレクト応答となり、 が指定された path (と query) で要求を受け取ったものとして再処理します。 >>313

[316] 両者の場合それぞれで、他の頭欄応答本体の有無、それを受け取ったの処理が異なります。 詳しくはそれぞれの項をご参照ください。

location 要素 (WebDAV)

[24] 207 応答に含まれる個別の状態符号3xx である場合、HTTP Location: ヘッダーのかわりに location 要素を使わなければなりません >>9, >>37201 の場合にも使えます >>37

[25] 内容は、要素内容であり、 href 要素1つです >>37href 要素内容Location: ヘッダーの値に相当します >>37

[39] response 要素子要素として使うことができます >>38

[40] propstat 要素では認められていません。

[36] クライアントは、 location 要素が指定されることに依存してはなりません。 指定されなかった場合には、個別の資源要求してリダイレクト先の URL を得られないか試しても構いません。 >>9

[35] この要素RFC 2518 にはなく、 RFC 4918 で追加されました。

歴史

[317] WWW-Talk Jan-Mar 1994: Re: Redirection: "Location" or "Uri" ? ( ( 版)) http://1997.webhistory.org/www.lists/www-talk.1994q1/0216.html

[452] RFC 1945 (HTTP/1.0) 10.11; RFC 2068・2616 (HTTP/1.1) 14.30 Location

The Location response-header field defines the exact location of the resource that was identified by the Request-URI is 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 must SHOULD 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.15 14.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 とは異なり、要求に同封された実体の場所を識別します。 従って、応答に LocationContent-Location の双方を含めることも可能です。 幾つかの方式のキャッシュ要求について、 13.10 節も参照。

注: 注記のない修正は、 RFC 1945→2068 での変更箇所。

[453] HTTP CGI/1.1 (draft 03) 7.2 (抜粋)

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 欄も供給してはいけません

7.2.1.2. Location

This is used to specify to the server that the script is returning a reference to a document rather than an actual document.

[10] これは、サーバーに対してスクリプトが実際の文書ではなく文書への参照を返すことを指定するのに使います。

  • [11] Location = "Location" ":" ( fragment-URI | rel-URL-abs-path ) NL
  • [12] fragment-URI = URI [ # fragmentid ]
  • [13] URI = scheme ":" *qchar
  • [14] fragmentid = *qchar
  • [15] rel-URL-abs-path = "/" [ hpath ] [ "?" query-string ]
  • [16] hpath = fpsegment *( "/" psegment )
  • [17] fpsegment = 1*hchar
  • [18] psegment = *hchar
  • [19] hchar = alpha | digit | safe | extra | ":" | "@" | "& | "="

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 値が経路である場合、サーバーは >>21URL を含む要求への応答であるとして応答を生成しなければなりません

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 は利用可能でないかもしれません。

00年代の実装

[45] 噂によると tok2 では広告の関係で CGI header Location: が使えないらしいです。

[46] >>45 トクトクは CGI 使えますと宣伝していましたよね。本当だとしたら虚偽広告ということになります。やめていただきたいね。

[28] サーバーによっては Cookie と相性が悪いようです。 (CGIでクッキーセットした後にLocationで他のURLに飛ばしたいんですが・・・ http://tohoho.wakusei.ne.jp/lng/199908/99080130.htm) ((200HTML 文書以外では Cookie は使わない方が良いですね。色々の実装状況的に。))

[50] >>28 これ、 LocationSet-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)

飛び先で文字化け問題

[30] 古い NC4 などで、

 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リダイレクトを参照してください。

相対 URL

...

RFC 723x

[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 BigQuery200Location: を使っています >>42

関連

[49] HTTP で、関連するプロトコル要素:

[32] w3mLocalCGI 機能で似たようなものとして w3m-Control: 欄 + GOTO があります。 w3m-control: GOTO file:///cgi-bin/foo.cgi のように使います。

[7] SSDPLOCATION: ヘッダーとは意味が異なります。

[44] WWW-Talk Jan-Mar 1994: Re: Redirection: "Location" or "Uri" ? ( 版) http://1997.webhistory.org/www.lists/www-talk.1994q1/0221.html

[47] Draft: PubSubHubbub Core 0.4 -- Working Draft ( 版) https://pubsubhubbub.googlecode.com/git/pubsubhubbub-core-0.4.html#anchor6

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

[76] Micropub () https://micropub.net/draft/#feature-li-16

Returning HTTP 202 Created and a Location header when creating a post

[77] Micropub () https://micropub.net/draft/#response-p-1

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]

[78] Compromise On Checkout - Vulnerabilities in SCM Tools · The Recurity Lablog ( ()) http://blog.recurity-labs.com/2017-08-10/scm-vulns

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