Edit

Page

Page title:

Page body:

[311] [DFN[[CODE(HTTP)@en[[[Content-Location:]]]]]] [[ヘッダー]]は、
[[payload]] に含まれる[[表現]]に対応する[[資源]]を識別する [[URL]]
を表すものです [SRC[>>13]]。

* 仕様書

[REFS[
- [13] '''[CITE@en[RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]] ([TIME[2014-06-07 01:55:45 +09:00]] 版) <https://tools.ietf.org/html/rfc7231#section-3.1.4>'''
- [335] [CITE@en[RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]] ([TIME[2014-06-07 01:55:45 +09:00]] 版) <https://tools.ietf.org/html/rfc7231#section-4.3.3>
- [24] [CITE@en[RFC 2295 - Transparent Content Negotiation in HTTP]] ([TIME[2014-08-31 19:36:42 +09:00]] 版) <http://tools.ietf.org/html/rfc2295#section-10.2>
- [26] [CITE@en[RFC 4918 - HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)]] ([TIME[2014-09-21 17:04:59 +09:00]] 版) <http://tools.ietf.org/html/rfc4918#section-5.2>
- [28] [CITE@en[RFC 5789 - PATCH Method for HTTP]] ([TIME[2014-09-22 15:11:26 +09:00]] 版) <http://tools.ietf.org/html/rfc5789#section-2>
- [30] [CITE@en[RFC 6968 - FCAST: Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols]] ([TIME[2014-09-14 18:07:31 +09:00]] 版) <https://tools.ietf.org/html/rfc6968#section-3.3>
- [32] [CITE@en[RFC 6968 - FCAST: Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols]] ([TIME[2014-09-14 18:07:31 +09:00]] 版) <https://tools.ietf.org/html/rfc6968#page-21>
- [34] [CITE@en[RFC 6968 - FCAST: Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols]] ([TIME[2014-09-14 18:07:31 +09:00]] 版) <https://tools.ietf.org/html/rfc6968#appendix-A.1>
]REFS]

* 構文

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

[FIG(railroad)[
= |
== [[ASCII]] [[絶対URL]] ([[素片識別子]]なし)
== [[ASCII]] [[相対URL]] ([[素片識別子]]なし)
]FIG]

* 文脈

[21] [CODE(HTTP)[[[304]]]] の項も参照。

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

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

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

* 意味

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

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

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

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

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

;; [316] [CODE(HTTP)@en[[[GET]]]] と [CODE(HTTP)@en[[[HEAD]]]] の場合は、
これは [CODE(HTTP)@en[[[Content-Location:]]]] がなかった場合と同じ動作です [SRC[>>13]]。

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

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

;; [23] [CODE(HTTP)@en[[[Prefer:]] [[return=representation]]]] の項も参照。

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

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

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

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

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

* 処理

[332] [[HTTP]] の [CODE(HTTP)@en[[[Content-Location:]]]] [[ヘッダー]]は、
無視する[['''べきです''']] [SRC[>>9]]。

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

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

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

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

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

* 基底 URL

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

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

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

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

* 表現の URL

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

[FIG(steps)[
= [15] [[要求]]の場合、
== [16] [CODE(HTTP)@en[[[Content-Location:]]]] [[ヘッダー]]があれば、
[[payload]] はこのヘッダーの値によって識別される[[資源]]の[[表現]]であると[[送信者]]が表明していることになります。ただし、何らかの他の手段で確認しない限り、
これが正しいとは保証されません。
== [17] そうでなければ、識別子はありません。
= [18] [[応答]]の場合、
-= [19] [[要求メソッド]]が [CODE(HTTP)@en[[[GET]]]] か [CODE(HTTP)@en[[[HEAD]]]]
であって、[[状態符号]]が [CODE(HTTP)[[[200]]]], [CODE(HTTP)[[[204]]]],
[CODE(HTTP)[[[206]]]], [CODE(HTTP)[[[304]]]] なら、
[[payload]] は[[実効要求URL]]によって識別される[[資源]]の[[表現]]です。
-= [305] [[要求メソッド]]が [CODE(HTTP)@en[[[GET]]]] か [CODE(HTTP)@en[[[HEAD]]]]
であって、[[状態符号]]が [CODE(HTTP)[[[203]]]] なら、
[[payload]] は[[対象資源]]の[[表現]]に、[[中間器]]が変更を加えたかもしれないものです。
-= [306] それ以外で[[応答]]が [CODE(HTTP)@en[[[Content-Location:]]]] [[ヘッダー]]を持っていて、
[[実効要求URL]]と同じ [[URL]] を表していれば、
[[payload]] は[[実効要求URL]]によって識別される[[資源]]の[[表現]]です。
-= [307] それ以外で[[応答]]が [CODE(HTTP)@en[[[Content-Location:]]]] [[ヘッダー]]を持っていて、
[[実効要求URL]]と違う [[URL]] を表していれば、
[[payload]] はこのヘッダーの値によって識別される[[資源]]の[[表現]]であると[[送信者]]が表明していることになります。ただし、何らかの他の手段で確認しない限り、
これが正しいとは保証されません。
-= [308] そうでなければ、識別子はありません。
]FIG]

;; [309] [[HTTP]] の仕様書上の[[資源]]や[[表現]]などの概念が複雑に定義されているために、
この定義も複雑になっています。 >>305 だけなぜか[[実効要求URL]]ではなく[[対象資源]]を使った定義になっていて、
[[対象資源]]の[[URL]]がほとんどの場合[[実効要求URL]]なので事実上等しいのですが、
なぜこう定義されているのか謎です。

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

* 歴史

** HTTP

[FIG(quote)[
[FIGCAPTION[
[11] RFC 2068 14.15; RFC 2616 14.14 Content-Location
]FIGCAPTION]

> 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]
]FIG]

** MHTML

[FIG(quote)[
[FIGCAPTION[
[12] RFC 2557 (MHTML)
]FIGCAPTION]

構文 :

- 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節に定義された算法を使って折畳むことが出来ます。
]FIG]

** 基底 URL

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

;; [328] ただし [CODE(HTTP)@en[[[Content-Base:]]]] は後に廃止されました。

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

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

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

[REFS[
- [3] [CITE[Bug 109553 – '''['''FIX''']'''Implement support for HTTP 1.1 Content-location header]]
([TIME[2009-10-05 00:15:32 +09:00]] 版)
<https://bugzilla.mozilla.org/show_bug.cgi?id=109553>
- [4] [CITE@en[Re: NEW ISSUE: Drop Content-Location]]
([[Ian Hickson]] 著, [TIME[2006-11-30 07:32:36 +09:00]] 版)
<http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0203.html>
- [7] [CITE[#154 (Content-Location base-setting problems) – httpbis]]
( ([TIME[2013-01-20 22:40:25 +09:00]] 版))
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/154>
- [20] [CITE@en[RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]] ([TIME[2014-08-07 05:54:02 +09:00]] 版) <https://tools.ietf.org/html/rfc7231#appendix-B>
- [9] [CITE@en[Tolerant HTTP Parsing]]
( ([TIME[2011-10-09 14:47:27 +09:00]] 版))
<http://stuff.gsnedders.com/http-parsing.html#rfc.section.B>
- [10] [CITE@en[HTTP - WHATWG Wiki]]
( ([TIME[2013-12-19 01:12:07 +09:00]] 版))
<http://wiki.whatwg.org/wiki/HTTP#Content-Location_header>
]REFS]

* メモ

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

[5] [CITE@en[RFC 4463 - A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks]]
( ([TIME[2011-12-04 10:31:11 +09:00]] 版))
<http://tools.ietf.org/html/rfc4463#section-5.4.8>

[6] [CITE@en[RFC 6787 - Media Resource Control Protocol Version 2 (MRCPv2)]]
( ([TIME[2012-11-13 15:18:40 +09:00]] 版))
<http://tools.ietf.org/html/rfc6787#section-6.2.10>

[8] [CITE[IRC logs: freenode / #whatwg / 20130117]]
( ([TIME[2013-01-18 21:01:10 +09:00]] 版))
<http://krijnhoetmer.nl/irc-logs/whatwg/20130117#l-766>

[FIG(quote)[
[FIGCAPTION[
[39] [CITE[HTTP::Response - search.cpan.org]]
([TIME[2015-03-15 12:30:47 +09:00]] 版)
<http://search.cpan.org/dist/HTTP-Message/lib/HTTP/Response.pm#%24r-%3Ebase>
]FIGCAPTION]

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

]FIG]

[FIG(quote)[
[FIGCAPTION[
[40] [CITE@en[Web Annotation Protocol]]
([TIME[2017-02-24 02:14:26 +09:00]])
<https://w3c.github.io/web-annotation/protocol/wd/#h-container-representations>
]FIGCAPTION]

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

]FIG]

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Errors

Page name(s)