#?SuikaWiki/0.9 page-icon="HTTP"

[[#comment]]


* 仕様書から


** RFC 2068 14.15; RFC 2616 14.14 Content-Location

> The Content-Location entity-header field [DEL[may]] [INS[MAY]] be used to supply the
resource location for the entity enclosed in the message[DEL[.]] [INS[when that entity is accessible from a location separate from the requested resource's URI. A server SHOULD provide a Content-Location for the variant corresponding to the response entity; especially in]] [DEL[In]] the case
where a resource has multiple entities associated with it, and those
entities actually have separate locations by which they might be
individually accessed, the server [DEL[should]] [INS[SHOULD]] provide a Content-Location
for the particular variant which is returned. [DEL[In addition, a server SHOULD provide a Content-Location for the resource corresponding to the response entity.]]

[CODE(HTTP)[Content-Location]] 実体頭欄は、[INS[メッセージ中の囲まれた実体が余給された資源の URI とは別の位置から接続可能であるときに]]その実体の資源位置を供給するのに使っても'''構いません'''。 [INS[サーバーは、応答実体に対応する変種の [CODE(HTTP)[Content-Location]] を提供する'''べきです'''。特に、]]資源がそれに関連付けられた複数の実体を持ち、それらの実体が個々に接続できる別の位置を実際に持つ場合には、
サーバーは返される特定の変種の [CODE(HTTP)[Content-Location]]
を提供する'''べきです'''。 [DEL[更に、サーバーは応答実体に対応する資源の [CODE(HTTP)[Content-Location]] を提供するべきです。]]

>
- Content-Location = "Content-Location" ":"
( absoluteURI | relativeURI )

> [DEL[If no Content-Base header field is present, the]] [INS[The]] value of Content-Location also defines the base [DEL[URL]] [INS[URI]] for the entity [DEL[(see section]]
14.11)]].

;[DEL[[CODE(HTTP)[[[Content-Base]]]] 頭欄が示されていないときには、]]
[CODE(HTTP)[Content-Location]] はその実体の基底 URI
をも定義します。

> The Content-Location value is not a replacement for the original
requested URI; it is only a statement of the location of the resource
corresponding to this particular entity at the time of the request.
Future requests MAY [DEL[use]] [INS[specify]] the Content-Location URI [INS[as the request-URI]] if the desire is to
identify the source of that particular entity.

[CODE(HTTP)[Content-Location]] 値は元の要求 URI の代替ではありません。
その要求の時点でのこの特定の実体に対応する資源の位置に言及するだけです。
将来の要求は、その特定の実体の典拠を特定するのに望まれるのであれば、
この [CODE(HTTP)[Content-Location]] URI を要求 URI として指定しても'''構いません'''。

> A cache cannot assume that an entity with a Content-Location
different from the URI used to retrieve it can be used to respond to
later requests on that Content-Location URI. However, the Content-Location can be used to differentiate between multiple entities
retrieved from a single requested resource, as described in section
13.6.

キャッシュは、実体を取り出すときに使った URI
とは異なる [CODE(HTTP)[Content-Location]] つきの実体をその後のその
[CODE(HTTP)[Content-Location]] URI への要求に使うことが出来ると仮定することは出来ません。
しかし、 [CODE(HTTP)[Content-Location]] は、13.6節で説明しているように、
単一の要求された資源から取り出された複数の実体同士を区別するのに使うことが出来ます。

> If the Content-Location is a relative URI, the [INS[relative]] URI is interpreted
relative to [DEL[any Content-Base URI provided in the response]] [INS[the Request-URI.]]. [DEL[If no Content-Base is provided, the relative URI is interpreted relative to the Request-URI.]]

[CODE(HTTP)[Content-Location]] が相対 URI であれば、その相対 URI
は[DEL[応答中で提供された [CODE(HTTP)[[[Content-Base]]]] URI]] [INS[[CODE(ABNF)[[[Request-URI]]]]]] に対して相対と解釈します。

[INS[

> The meaning of the Content-Location header in PUT or POST requests is
undefined; servers are free to ignore it in those cases.

[CODE(HTTP)[[[PUT]]]] 要求や [CODE(HTTP)[[[POST]]]]
要求における [CODE(HTTP)[Content-Location]] 頭の意味は未定義です。
サーバーはこの場合に [CODE(HTTP)[Content-Location]]
を無視するのも自由です。
]INS]


** RFC 2557 (MHTML)

構文 :

- content-location =   "Content-Location:" [CFWS] URI [CFWS]
- URI              =   absoluteURI | relativeURI

規定抜粋:


*** 4.4.1 Encoding of URIs containing inappropriate characters [INS[不適切な文字を含む URI の符号化]]

> Some documents may contain URIs with characters that are
inappropriate for an RFC 822 header, either because the URI itself
has an incorrect syntax according to [URL] or the URI syntax standard
has been changed to allow characters not previously allowed in MIME
headers. These URIs cannot be sent directly in a message header. If
such a URI occurs, all spaces and other illegal characters in it must
be encoded using one of the methods described in [MIME3] section 4.
This encoding MUST only be done in the header, not in the HTML text.
Receiving clients MUST decode the [MIME3] encoding in the heading
before comparing URIs in body text to URIs in Content-Location headers.

URI 自体が [[RFC1738]] によれば間違っている構文であるか、又は URI
構文規格が変更されて MIME 頭で従来認められていない文字が許されるようになったために
[[RFC822]] 頭には不適切な文字をもつ URI を含んだ文書もあるかもしれません。
そうした URI はメッセージ頭中で直接は送信できません。そのような URI
があった場合、その中の全ての間隔と他の不正な文字は [[RFC2047]]
4章の方法 [INS[([[encoded-word]])]] の1つを使って符号化しなければなりません。
この符号化は、 [[HTML]] 文中ではなく、頭中においてのみ行わなければ'''なりません'''。
受信したクライアントは、本体文中の URI を [CODE(MIME)[Content-Location]]
頭中の URI と比較する前に RFC 2047 符号化を復号しなければ'''なりません'''。


*** 4.4.2 Folding of long URIs [INS[長い URI の折畳み]]

> Since MIME header fields have a limited length and long URIs can
result in Content-Location headers that exceed this length, 
Content-Location headers may have to be folded.

MIME 頭欄は長さに制限があるので、長い URI があると [CODE(MIME)[Content-Location]]
頭はこの長さを超えることにな得るので、
[CODE(MIME)[Content-Location]] 頭は折畳まなければならないかもしれません。

> Encoding as discussed in clause 4.4.1 MUST be done before such
folding.  After that, the folding can be done, using the algorithm
defined in [URLBODY] section 3.1.

4.4.1節で触れた符号化はこの折畳みの前に行わなければ'''なりません'''。
その後、 [[URLBODY]] 3.1節に定義された算法を使って折畳むことが出来ます。


** RFC の部分の License

[[RFCのライセンス]]


* メモ

[1]
[CITE@ja[Livedoor clipがContent-Locationヘッダの参照先をブックマークする件 (kuruman.org > Kuruman Memo)]] ([CODE[2007-01-29 16:17:52 +09:00]] 版) <http://kuruman.org/diary/2007/01/29/content-location-sbm>
([[名無しさん]] [WEAK[2007-01-29 07:33:06 +00:00]])

[2]
[CITE@ja[Content-Locationの出力やめた (kuruman.org > Kuruman Memo)]] ([TIME[2007-03-20 02:54:24 +09:00]] 版) <http://kuruman.org/diary/2007/03/20/delete-content-location-header>
([[名無しさん]] [WEAK[2007-03-20 01:07:58 +00:00]])