Content-Location:欄

Content-Location: ヘッダー (MIME、HTTP)

[311] Content-Location: ヘッダーは、 payload に含まれる表現に対応する資源を識別する URL を表すものです >>13

仕様書

構文

[313] HTTP においては、値は、 RFC 3986 absolute-URI または RFC 7230 partial-URI です >>13。すなわち、 素片識別子を含まない URL です。

  1. |
    1. ASCII 絶対URL (素片識別子なし)
    2. ASCII 相対URL (素片識別子なし)

文脈

[21] 304 の項も参照。

[25] 選択応答には最善の異体URL を表す Content-Location: ヘッダーを含めなければなりません >>24

[27] WebDAV コレクションの末尾の / を省略した URL についての応答は、末尾に / を含む URLContent-Location: ヘッダーを含めるべきです >>26

[31] FCAST でも使うことができます >>30

意味

[312] Content-Location: ヘッダーは、 payload に含まれる表現に対応する資源を識別する URL を表すものです >>13。これはすなわち、当該メッセージ生成の時点でその URLGET 要求を送信すると、 200 応答が同じ表現を含むであろうことを表します >>13

[314] この値は実効要求URLの代わりとなるものではなく、 表現メタデータです >>13

[333] 表現メタデータとしての URL、というものがどういう意味のものなのかよくわかりませんが...

[324] HTTP 要求メッセージに指定されている場合、利用者エージェントが元々その URL表現を取得して (場合によっては変更を加えて) 要求に含めたことを示しています。 >>13

[315] HTTP 2xx 応答に含まれている場合、 絶対URL解決したら実効要求URL と同じになる場合は、受信者は、 payloadメッセージの生成時刻における当該資源表現であると考えて構いません >>13

[316] GETHEAD の場合は、 これは Content-Location: がなかった場合と同じ動作です >>13
[317] PUTPOST のような状態を変更する要求の場合は、 応答が「成功しました」のような結果報告であるのか、 新しい表現であるのかを Content-Location: によって区別できます。 >>13 (クライアント側のキャッシュのようなものを更新することが想定されているようです。)

[318] Content-Location: ヘッダー2xx 応答に含まれている場合で、実効要求URLと異なる場合には、 起源鯖がその URL資源表現であると主張していることになります。 この主張が正しいかどうかは HTTP としては機械的に決められません。 >>13

[320] GETHEAD 要求に対する応答>>318 のようである場合、 実効要求URL内容折衝の対象となる資源を表していて、 Content-Location: は選択された表現を識別する URL となっていることを示しています >>13

[321] Apache内容折衝を有効にすると、そのような Content-Location: が実際に設定されます。 ただし、 Apache はその指定された URL が実際にアクセス可能であることを保証していません。 特に複雑な URL の書き換えが Apache 内部で行われる場合など、 実在しない URL が指定されることがよくあります。 これは Content-Location: が実際には意味を持たない理由の一つでもあります。

[322] 状態を変更するメソッドに対する 201 応答>>318 のようである場合、 Content-LocationLocation が等しければ、 payload が新しく作られた資源の現在の表現であることを示しています >>13

[334] 起源鯖は、 POST への応答キャッシュさせて以後の GET の処理で再利用できるようにしたい時は、 200 応答を送り、その Content-Location: ヘッダー実効要求URLと同じ値を設定することができます >>335

[323] それ以外で >>318 のようである場合、 payload要求された動作の状態を報告するもので、 同じ報告が指定された URLGET することで得られることを示しています。 >>13

処理

[332] HTTPContent-Location: ヘッダーは、 無視するべきです >>9

[325] 起源鯖は、要求メッセージContent-Location: を受信した時は、これをそのまま表現の一部として保存するメタデータとしてではなく、 一時的な文脈情報として扱わなければなりません起源鯖はこれを処理の補助に用いたり、情報源を表すリンクに用いたりしても構いませんが、 要求の意味を変える情報として使ってはなりません >>13

[326] 例えば、ある URL内容折衝で複数の表現が提供されている時に、 特定の表現だけを更新するために、 PUT 要求Content-Location を指定する、といった使い方はできません >>13

[22] Content-Location: ヘッダーの値は、 キャッシュ非妥当化に使われることもあります。

[29] Content-Location: ヘッダーの値は、 PATCH 要求に対する応答キャッシュ可能性の判定にも用いられます >>28

[33] FCAST の実装は、 Content-Location: HTTPヘッダーに対応しなければなりません >>32

基底 URL

[35] Content-Location: を解釈するための基底URLは、 対象URLです。

[38] これはHTTP一般における基底URLと同じです。 (HTTPにおける基底URL 参照。)

[36] FCAST においても相対URLを使った例が示されています >>34 が、対象URLに相当するものは無く、何が基底URLとなるのかは不明です。

[37] なお、歴史的には Content-Location: で指定された URL が他のヘッダー本体に含まれる相対URL基底URL として使われるとされたこともありましたが、広く実装されることはありませんでした。

表現の URL

[14] HTTP における表現URL は、次のように定義されています >>13

  1. [15] 要求の場合、
    1. [16] Content-Location: ヘッダーがあれば、 payload はこのヘッダーの値によって識別される資源表現であると送信者が表明していることになります。ただし、何らかの他の手段で確認しない限り、 これが正しいとは保証されません。
    2. [17] そうでなければ、識別子はありません。
  2. [18] 応答の場合、
    1. [19] 要求メソッドGETHEAD であって、状態符号200, 204, 206, 304 なら、 payload実効要求URLによって識別される資源表現です。
    2. [305] 要求メソッドGETHEAD であって、状態符号203 なら、 payload対象資源表現に、中間器が変更を加えたかもしれないものです。
    3. [306] それ以外で応答Content-Location: ヘッダーを持っていて、 実効要求URLと同じ URL を表していれば、 payload実効要求URLによって識別される資源表現です。
    4. [307] それ以外で応答Content-Location: ヘッダーを持っていて、 実効要求URLと違う URL を表していれば、 payload はこのヘッダーの値によって識別される資源表現であると送信者が表明していることになります。ただし、何らかの他の手段で確認しない限り、 これが正しいとは保証されません。
    5. [308] そうでなければ、識別子はありません。
[309] HTTP の仕様書上の資源表現などの概念が複雑に定義されているために、 この定義も複雑になっています。 >>305 だけなぜか実効要求URLではなく対象資源を使った定義になっていて、 対象資源URLがほとんどの場合実効要求URLなので事実上等しいのですが、 なぜこう定義されているのか謎です。

[310] この方法で決定された URL がどのような場面で使われるのかは謎です。 Webブラウザー応答URL基底URL として使われるのは、この URL ではなく対象URLです。

歴史

HTTP

[11] RFC 2068 14.15; RFC 2616 14.14 Content-Location

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.

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

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

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 URI Request-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.

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

基底 URL

[327] Content-Location:Content-Base: は、元々はHTTPメッセージ基底URLを明示するものとの役割も持っていました。

[328] ただし Content-Base: は後に廃止されました。

[329] しかし実際にはどのWebブラウザーもこれを実装しておらず、 はしばしば壊れた値を出力していたため、 実装しようとすることで既存の Webサイトが壊れることがわかりました >>3

[330] Webブラウザー側は Content-Location: は意味を成さないとして無視することを求めています >>4, >>9, >>10 が、 IETF HTTP WG基底URLとしての役割を削除した >>7, >>20 のみで、ヘッダー自体は削除しませんでした。

[331] ただし、実用上唯一の機能が基底URLを指定するものとしての役割でしたから、 その削除によって事実上役割を失っています。

メモ

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

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

[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>

[8] IRC logs: freenode / #whatwg / 20130117 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20130117#l-766>

[39] HTTP::Response - search.cpan.org ( 版) <http://search.cpan.org/dist/HTTP-Message/lib/HTTP/Response.pm#%24r-%3Ebase>

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.