Content-Base:欄

Content-Base: ヘッダー (MIME, HTTP)

[13] Content-Base: は、 HTTPMIMEメッセージにおける基底URL を指定するものとして提案されていたヘッダーでした。

[28] このヘッダーは広く実装されること無く削除されました。

[29] 本項は廃止された HTTP および MIME の機能に関するものです。本項の事項は当時の状況を説明するもので、 現状とは異なることがあります。

[14] 仕様書:

構文

[15] RFC 2110 では RFC 822ABNF を使って

content-base ::= "Content-Base:" absoluteURI

と構文が定義されていました。ここで、 absoluteURI の定義については明確な説明がありませんが、 URI は RFC 1738 の定義に制限されると書いてあるので、 RFC 1738 で規定されている絶対URL を表すのでしょう。 (absoluteURL でなくて absoluteURI なのは既に RFC 2396 の策定作業中であったからでしょう。)

[16] >>15RFC 822ABNF で記述されていますが、 RFC 822 的には欄本体の前後には LWS が挿入できると考える方が適当です。実際 RFC 2110 の改訂版の RFC 2557 には (Content-Base の定義はありませんが、一緒に定義されていた Content-Location は) ABNFCFWS (LWSRFC 2822 版) を使うように修正されています。

それを考慮して定義を書き直すと、

content-base := "Content-Base:" [CFWS] absolute-URI [CFWS]

となります。まあ書き直すというほどの違いではありませんが。 RFC 1738URL というのはいくらなんでも古過ぎるので、 勝手に RFC 3986absolute-URI に変えさせて頂きました。

実は欄本体の末尾に CFWS が書けるというのには問題があります。 (URI なのか comment なのか判断できないことがあります。詳しくは Content-Location: 欄の解説をご覧下さい。

[6] URLBODY: さて、話は >>15-16 で終わりではありません。 RFC 2110 4.4 によれば、 URIMIME の頭欄の行長制限 (そんなのあったか?) を超え得るので、 URLBODY 3.1 節の方法を採用するとしています。 簡単に言えば、引用符で括れば空白URI の途中に勝手に挿入してもよいということです。

これを考慮すると:

content-base := "Content-Base:" [CFWS] (absolute-URI / quoted-absolute-URI) [CFWS]
quoted-absolute-URI := <"> URI-word *(FWS URI-word) <">
    ;; FWS を除去すると、 absolute-URI になること
URI-word := 1*40(%x21 / %x23-5B / %x5D-7E)
    ;; CTL, SP, <">, "\", 8ビットを除くもの

(URLBODY の仕様上の問題を補正済み。詳しくは URLBODY の解説を参照。)

[17] Content-Location: 新規格との整合性: RFC 2110 では Content-BaseContent-Location が共に規定されていましたが、 新しい RFC 2557Content-Location だけを規定しています。どちらの欄も元々ほとんど構文等は同じでしたが、 RFC 2557 では encoded-word に関する規定が加わっています。

両欄の整合性を考えるなら、 Content-BaseContent-Location とほぼ同じように処理するべきです。

Content-Location: 欄の解説に新しい構文についての考察があります。

[21] >>6 実装は URLBODY の方法を使うというのを引用符で囲むのも含めてと解釈していますけど (>>12)、それは本当に RFC 2110 の意図なのでしょうか? URLBODYmessage/external-body媒体型引数だから引用符も含めて定義しているだけで、 欄本体で使うなら引用符をわざわざ含める必然性はないのですから。

でも RFC 2110 を厳密に読んだら確かに引用符が必要と解釈するのが自然な気もする。仕様書が曖昧なのが一番問題だな。

文脈

[31] Mozilla Thunderbirdフィードリーダー機能のメッセージでは、 エントリーの記事 (HTML) の URL (引用符等のない絶対URLで) が Content-Base: に設定されます。 (素片識別子付きのこともあります。)

意味

[18] 適用範囲: RFC 2110 には、Content-BaseContent-Location が適用されるのはその実体そのものだけであり、 multipart/*実体に指定しても内側の実体本体には適用されないと規定されています RFC 2110 4.1

が、それに反する例もあります RFC 2110 9.3Content-Location の改訂版の RFC 2557 には相当する規定が無いので、撤回されたものと思われます。

歴史

RFC 2110 (MHTML)

[3] RFC 2110 (>>2) をご覧下さい。

HTTP

RFC 2068

[2] RFC 2068 (HTTP/1.1) 14.11 Content-Base

[19]

The Content-Base entity-header field may be used to specify the base URI for resolving relative URLs within the entity. This header field is described as Base in RFC 1808, which is expected to be revised.

Content-Base 実体頭欄は、実体中の相対URL解決するための基底URI を指定するために使うことができます。 この頭欄は、改訂が期待される RFC 1808Base 欄として説明されているものです。

[20]

[4]

If no Content-Base field is present, the base URI of an entity is defined either by its Content-Location (if that Content-Location URI is an absolute URI) or the URI used to initiate the request, in that order of precedence. Note, however, that the base URI of the contents within the entity-body may be redefined within that entity-body.

Content-Base 欄が無ければ、実体基底URI実体Content-Location (Content-Location絶対URI の場合。) 又は要求初期化するのに使った URI のいずれかにより、 この優先順で定義されます。 ただし、実体本体中の内容の基底URI実体本体中で再定義されるかもしれないことに注意して下さい。

RFC 2616

[23] RFC 2616 は使われていないし導入するのも難しい、 MHTML とも仕様が微妙に違うため削除するとしています >>5, >>11

RFC 4229

[26] RFC 4229RFC 2068 を出典に IANA登録簿に登録しています >>24。 状態は「標準」となっていました >>24

[27] 現在は RFC 2068RFC 2616 が出典となっており、 状態は「廃止済み」になっています >>25

実装

[12] >>8-11 Mozilla (Not Classic Mozilla) 系 MUA (Mozilla Suite の MUA とか、 Thunderbird とか) で非 local の文書を添付して送ると Content-BaseContent-Location 両方>>8 のように [URLBODY] を使ったものになるようです。 (名無しさん 2004-08-05 11:25:36 +00:00)

[22] Thundirbird 1.5 はRSS電子メイルのような 822 + MIMEらしき形式に変換して処理しているようですが、 その中で元の基底URIを保存するためのContent-Base: 欄が使われています。

関連

[1] 似たものとして Content-Location: 欄があります。どちらもあまり有効に使われていないのが実情で、 意味的に多少違いがあるのですが、新しい規格では Content-Location だけ残して Content-Base は削除されています。

統計

[823] HTTP/1.1 Content-Base header ( 版) http://www.http-stats.com/Content-Base

[824] >>823 によると Lotus-Domino が吐きまくっているみたいです。

[8] URLBODY の方法で分割された例

Content-Base: "http://foo.example/
   path/to/base/URI
   /%28very%20very%20long%2E%29?foo=bar;bar=foo"

[9] >>8 というかそもそも Content-Base: 欄が使われているの自体はじめてみました。 ちなみに Content-Location: 欄と併用されてはいませんでした。

関連

[10] 本来はその名の通り CL は位置、 CB は基底だったんですけどねぇ。 CL 指定すれば敢えて CB 指定する必要はないし。 (意味的には確かに異なるけど、実際必要な場面ってねぇ。)

[7] 相対URI でも良い Content-Location: 欄に対して、 Content-Base: 欄は絶対URI しか使えません。

[825] HTML::HeadParser - search.cpan.org ( 版) http://search.cpan.org/~gaas/HTML-Parser-3.64/lib/HTML/HeadParser.pm

[826] IANA | Permanent Message Header Field Registry ( ( 版)) http://www.iana.org/assignments/message-headers/perm-headers.html

[827] HTML::HeadParser - search.cpan.org ( 版) http://search.cpan.org/dist/HTML-Parser/lib/HTML/HeadParser.pm

[828] RFC 4463 - A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks ( ( 版)) http://tools.ietf.org/html/rfc4463#section-5.4.6

[829] RFC 6787 - Media Resource Control Protocol Version 2 (MRCPv2) ( ( 版)) http://tools.ietf.org/html/rfc6787#section-6.2.8

[830] 3248 – HTTP headers are not passed on to main NGLayout code [IMPORT] ( ( 版)) https://bugzilla.mozilla.org/show_bug.cgi?id=3248

[831] RFC Errata Report ( ( 版)) http://www.rfc-editor.org/errata_search.php?rfc=4229

[30] 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.