[311] Content-Location: ヘッダーは、
payload に含まれる表現に対応する資源を識別する URL
を表すものです >>13。
[313] HTTP においては、値は、 RFC 3986 absolute-URI
または RFC 7230 partial-URI です >>13。すなわち、
素片識別子を含まない URL です。
[25] 選択応答には最善の異体の URL を表す Content-Location:
ヘッダーを含めなければなりません >>24。
[27] WebDAV コレクションの末尾の / を省略した URL
についての応答は、末尾に / を含む URL の
Content-Location: ヘッダーを含めるべきです >>26。
[312] Content-Location: ヘッダーは、
payload に含まれる表現に対応する資源を識別する URL
を表すものです >>13。これはすなわち、当該メッセージの生成の時点でその URL
に GET 要求を送信すると、 200
応答が同じ表現を含むであろうことを表します >>13。
[314] この値は実効要求URLの代わりとなるものではなく、 表現メタデータです >>13。
[324] HTTP 要求メッセージに指定されている場合、利用者エージェントが元々その URL の表現を取得して (場合によっては変更を加えて) 要求に含めたことを示しています。 >>13
[315] HTTP 2xx 応答に含まれている場合、
絶対URLに解決したら実効要求URL と同じになる場合は、受信者は、 payload
がメッセージの生成時刻における当該資源の表現であると考えて構いません >>13。
PUT や POST のような状態を変更する要求の場合は、
鯖の応答が「成功しました」のような結果報告であるのか、
新しい表現であるのかを Content-Location:
によって区別できます。 >>13
(クライアント側のキャッシュのようなものを更新することが想定されているようです。)[318] Content-Location: ヘッダーが 2xx
応答に含まれている場合で、実効要求URLと異なる場合には、
起源鯖がその URL の資源の表現であると主張していることになります。
この主張が正しいかどうかは HTTP としては機械的に決められません。 >>13
Prefer: return=representation の項も参照。[320] GET や HEAD
要求に対する応答が >>318 のようである場合、
実効要求URLが内容折衝の対象となる資源を表していて、
Content-Location: は選択された表現を識別する URL
となっていることを示しています >>13。
Content-Location: が実際に設定されます。
ただし、 Apache はその指定された URL が実際にアクセス可能であることを保証していません。
特に複雑な URL の書き換えが Apache 内部で行われる場合など、
実在しない URL が指定されることがよくあります。
これは Content-Location: が実際には意味を持たない理由の一つでもあります。[322] 状態を変更するメソッドに対する 201
応答が >>318 のようである場合、
Content-Location と Location
が等しければ、 payload が新しく作られた資源の現在の表現であることを示しています
>>13。
[334] 起源鯖は、 POST への応答をキャッシュさせて以後の
GET の処理で再利用できるようにしたい時は、
200 応答を送り、その Content-Location:
ヘッダーに実効要求URLと同じ値を設定することができます >>335。
[323] それ以外で >>318 のようである場合、 payload は要求された動作の状態を報告するもので、
同じ報告が指定された URL を GET することで得られることを示しています。
>>13
[332] HTTP の Content-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。
[35] Content-Location: を解釈するための基底URLは、
対象URLです。
[36] FCAST においても相対URLを使った例が示されています >>34 が、対象URLに相当するものは無く、何が基底URLとなるのかは不明です。
[14] HTTP における表現の URL は、次のように定義されています >>13。
GET か HEAD
であって、状態符号が 200, 204,
206, 304 なら、
payload は実効要求URLによって識別される資源の表現です。GET か HEAD
であって、状態符号が 203 なら、
payload は対象資源の表現に、中間器が変更を加えたかもしれないものです。Content-Location: ヘッダーを持っていて、
実効要求URLと同じ URL を表していれば、
payload は実効要求URLによって識別される資源の表現です。Content-Location: ヘッダーを持っていて、
実効要求URLと違う URL を表していれば、
payload はこのヘッダーの値によって識別される資源の表現であると送信者が表明していることになります。ただし、何らかの他の手段で確認しない限り、
これが正しいとは保証されません。[310] この方法で決定された URL がどのような場面で使われるのかは謎です。 Webブラウザーで応答の URL や基底URL として使われるのは、この URL ではなく対象URLです。
The Content-Location entity-header field
mayMAY 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 inInthe 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 servershouldSHOULD 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, theThe value of Content-Location also defines the baseURLURI for the entity(see section14.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
usespecify 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 responsethe 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
を無視するのも自由です。
構文 :
規定抜粋:
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 符号化を復号しなければなりません。
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節に定義された算法を使って折畳むことが出来ます。
[327] Content-Location: や Content-Base:
は、元々はHTTPメッセージの基底URLを明示するものとの役割も持っていました。
Content-Base: は後に廃止されました。[329] しかし実際にはどのWebブラウザーもこれを実装しておらず、 鯖はしばしば壊れた値を出力していたため、 実装しようとすることで既存の Webサイトが壊れることがわかりました >>3。
[330] Webブラウザー側は Content-Location:
は意味を成さないとして無視することを求めています >>4, >>9, >>10 が、
IETF HTTP WG は基底URLとしての役割を削除した >>7, >>20
のみで、ヘッダー自体は削除しませんでした。
[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>
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.
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.