[1] URI: ヘッダー は HTTP92 で存在していました。その資源自身が手に入ろう URI を示すようです。内容折衝に使うことが考えられていたようです。 multipart/related では今で言う Content-Location: 欄の役割も期待されていました。 (Object Header lines in HTTP <http://www.w3.org/Protocols/HTTP/Object_Headers.html#uri>)
URI:
[10] この欄の機能には代替の欄が既に存在していますから、 この欄は使用しないのが良いでしょう。
[11] Object Header lines in HTTP (2002-04-11 00:31:17 +09:00 版) <http://www.w3.org/Protocols/HTTP/Object_Headers.html#uri>
This gives a URI with which the object may be found. There is no guarantee that the object can be retrieved using the URI specified. However, it is guaranteed that if an object is successfully retrieved using that URI it will be to a certain given degree the same object as this one.
これはその物体が見つかるかもしれない URI を与えます。 その指定された URI で物体を取り出せる保証はありません。 しかし、物体をその URI から取り出すのに成功したなら、 この物体とその物体がある程度は同じであろうという保証はあります。
If the URI is used to refer to a set of variants, then the dimensiosn (ママ) in which the variants may differ must be given with the "vary" parameter:
URI を変形の集合を参照するのに使うときには、 vary 引数を使ってその変形がどの次元で異なるものであるのかを指定しなければなりません。
vary
If no "vary" parameters are given, then the URI may not return anything other than the same bit stream as this object.
vary 引数が与えられていなければ、 URI はこの物体と同じビット列のもの以外を返してはいけません。
Multiple occurencies of this field give alternative access names or addresses for the object.
この欄を複数出現させることで、 その物体の代替の名前又は番地を与えることが出来ます。
ExamplesURI: http://www.w3.org/pub/www/doc/url6.multi; vary=content-type
Examples
This indicates that retrieval given the URI will return the same document, never an updated version, but optionally in a different rendition.
これは、この URI で取り出すと、同じ文書 (更新された版ではないが、異なる rendering かもしれない。) が返されることを示します。
This indicates that the URI will return the same document, possibly in a different rendition, possibly updated, and without excluding the provision of translations into different languages.
これは、この URI が同じ文書を返しますが、 それは異なる rendering かもしれず、更新されているかも知れず、 異なる言語への翻訳であるかもしれないことを示しています。
This indicates that accessing the URI in question will return exactly the same bitstream.
これは、当該 URI に access すると全く同じビット列が返されることを示します。
[4] libwwwは1994年11月25日の2.17 Release以後、 Location: の意味の URI: に対応したようです。
Location:
[12] RFC 1945 (HTTP/1.0) D.2.10 URI
The URI entity-header field may contain some or all of the Uniform Resource Identifiers (Section 3.2) by which the Request-URI resource can be identified. There is no guarantee that the resource can be accessed using the URI(s) specified.
URI 実体頭欄は、 Request-URI 資源を識別できる URI の幾つか又は全てを含めることが出来ます。 指定された URI を使って資源に接触できるという保証はありません。
URI
Request-URI
[15] RFC 2068 で「追加機能」 >>14 として追加されました。 ただし非推奨 (deprecated) とされています >>14。
[13] RFC 2068 (HTTP/1.1) 19.6.2.5 URI
The URI header field has, in past versions of this specification, been used as a combination of the existing Location, Content-Location, and Vary header fields as well as the future Alternates field (above). Its primary purpose has been to include a list of additional URIs for the resource, including names and mirror locations. However, it has become clear that the combination of many different functions within this single field has been a barrier to consistently and correctly implementing any of those functions. Furthermore, we believe that the identification of names and mirror locations would be better performed via the Link header field. The URI header field is therefore deprecated in favor of those other fields.
URI 頭欄は、この仕様書の過去の版で、 既存の Location, Content-Location, Vary 各頭欄, 将来の Alterbate 欄 (前述) を組合せたものとして定義されていました。 その主目的は、名前や鏡像位置を含む資源の追加の URI の一覧を含めることです。 しかし、多くの異なる機能を単一の欄に組合せることは全ての機能を一貫して正しく実装することの障壁となることが明らかとなりました。 更に、名前や鏡像位置の識別は Link 頭欄を使った方がより望ましいと信じています。従って他の欄がある URI 頭欄は非推奨とします。
Location
Content-Location
Vary
Alterbate
Link
[7] RFC 2616 はあまり使われていないとして削除しました >>9。
PATCH
Content-Disposition:
[18] IANA登録簿には RFC 4229 により RFC 2068 を出典に登録されています >>16, >>17。
[19] 状態は「標準」となっています >>16。ただし一覧表では空欄になっています >>17。
[5] HTTP/1.1 URI header (2009-07-19 12:16:02 +09:00 版) <http://www.http-stats.com/URI>
[6] >>5 ほとんどは特定の実装の誤りかなにかでしょうね。
[3] この前 Internet Archive で見つけましたよ。1996年くらいだったかな。 URI: <foo.html> 見たいな感じの相対 URI だった。 (名無しさん 2004-05-20 00:39:49 +00:00)
[22] RFC Errata Report ( (2014-12-03 17:38:35 +09:00 版)) <http://www.rfc-editor.org/errata_search.php?rfc=4229>
[23] mod_proxy - Apache HTTP Server Version 2.4 (2015-02-15 17:51:02 +09:00 版) <http://httpd.apache.org/docs/current/en/mod/mod_proxy.html#ProxyPassReverse>
This directive lets Apache httpd adjust the URL in the Location, Content-Location and URI headers on HTTP redirect responses.