The Content-Location entity-header field may MAY be used to supply the
resource location for the entity enclosed in the message. 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 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 should SHOULD provide a Content-Location
for the particular variant which is returned. In addition, a server SHOULD provide a Content-Location for the resource corresponding to the response entity.
If no Content-Base header field is present, the The value of Content-Location also defines the base URL URI for the entity (see section
14.11)]].
;Content-Base 頭欄が示されていないときには、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 use specify the Content-Location URI as the request-URI if the desire is to
identify the source of that particular entity.
Content-Location 値は元の要求 URI の代替ではありません。
その要求の時点でのこの特定の実体に対応する資源の位置に言及するだけです。
将来の要求は、その特定の実体の典拠を特定するのに望まれるのであれば、
この 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
とは異なる Content-Location つきの実体をその後のその
Content-Location URI への要求に使うことが出来ると仮定することは出来ません。
しかし、 Content-Location は、13.6節で説明しているように、
単一の要求された資源から取り出された複数の実体同士を区別するのに使うことが出来ます。
If the Content-Location is a relative URI, the relative URI is interpreted
relative to any Content-Base URI provided in the response the Request-URI.. If no Content-Base is provided, the relative URI is interpreted relative to the Request-URI.
Content-Location が相対 URI であれば、その相対 URI
は応答中で提供された Content-Base URIRequest-URI に対して相対と解釈します。
The meaning of the Content-Location header in PUT or POST requests is
undefined; servers are free to ignore it in those cases.
PUT 要求や POST
要求における Content-Location 頭の意味は未定義です。
サーバーはこの場合に Content-Location
を無視するのも自由です。
MHTML
[12] RFC 2557 (MHTML)
構文 :
content-location = "Content-Location:" [CFWS] URI [CFWS]
URI = absoluteURI | relativeURI
規定抜粋:
4.4.1 Encoding of URIs containing inappropriate characters 不適切な文字を含む 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章の方法 (encoded-word) の1つを使って符号化しなければなりません。
この符号化は、 HTML 文中ではなく、頭中においてのみ行わなければなりません。
受信したクライアントは、本体文中の URI を Content-Location
頭中の URI と比較する前に RFC 2047 符号化を復号しなければなりません。
4.4.2 Folding of long URIs 長い 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 があると Content-Location
頭はこの長さを超えることにな得るので、
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.
[5] RFC 4463 - A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks
( ( 版))
http://tools.ietf.org/html/rfc4463#section-5.4.8
[6] RFC 6787 - Media Resource Control Protocol Version 2 (MRCPv2)
( ( 版))
http://tools.ietf.org/html/rfc6787#section-6.2.10
A "Content-Base:" or a "Content-Location:" header in the response.
For backwards compatibility with older HTTP implementations we will also look for the "Base:" header.
[40] Web Annotation Protocol
()
https://w3c.github.io/web-annotation/protocol/wd/#h-container-representations
The IRI of the Container provided in the response should differentiate between whether the pages contain just the IRIs, or the full descriptions of the Annotations. It is recommended that this be done with a query parameter. The server may redirect the client to this IRI and deliver the response there, otherwise it must include a Content-Location header with the IRI as its value.