[13] Content-Base:
は、
HTTP や MIME のメッセージにおける基底URL
を指定するものとして提案されていたヘッダーでした。
[28] このヘッダーは広く実装されること無く削除されました。
[29] 本項は廃止された HTTP および MIME の機能に関するものです。本項の事項は当時の状況を説明するもので、 現状とは異なることがあります。
[14] 仕様書:
[15] RFC 2110 では RFC 822 の ABNF を使って
content-base ::= "Content-Base:" absoluteURI
と構文が定義されていました。ここで、 absoluteURI
の定義については明確な説明がありませんが、
URI は RFC 1738 の定義に制限される
と書いてあるので、
RFC 1738 で規定されている絶対URL
を表すのでしょう。
(absoluteURL
でなくて absoluteURI
なのは既に RFC 2396 の策定作業中であったからでしょう。)
[16] >>15 は RFC 822 の ABNF で記述されていますが、
RFC 822 的には欄本体の前後には LWS
が挿入できると考える方が適当です。実際 RFC 2110
の改訂版の RFC 2557 には (Content-Base
の定義はありませんが、一緒に定義されていた Content-Location
は) ABNF で CFWS
(LWS
の RFC 2822 版)
を使うように修正されています。
それを考慮して定義を書き直すと、
content-base := "Content-Base:" [CFWS] absolute-URI [CFWS]
となります。まあ書き直すというほどの違いではありませんが。
RFC 1738 の URL というのはいくらなんでも古過ぎるので、
勝手に RFC 3986 の absolute-URI
に変えさせて頂きました。
[6] URLBODY: さて、話は >>15-16 で終わりではありません。 RFC 2110 4.4 によれば、 URI は MIME の頭欄の行長制限 (そんなのあったか?) を超え得るので、 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-Base
と
Content-Location
が共に規定されていましたが、
新しい RFC 2557 は Content-Location
だけを規定しています。どちらの欄も元々ほとんど構文等は同じでしたが、
RFC 2557 では encoded-word
に関する規定が加わっています。
両欄の整合性を考えるなら、 Content-Base
も Content-Location
とほぼ同じように処理するべきです。
Content-Location:
欄の解説に新しい構文についての考察があります。
[21]
>>6 実装は URLBODY の方法を使うというのを引用符で囲むのも含めてと解釈していますけど
(>>12)、それは本当に
RFC 2110 の意図なのでしょうか? URLBODY は
message/external-body
の媒体型引数だから引用符も含めて定義しているだけで、
欄本体で使うなら引用符をわざわざ含める必然性はないのですから。
でも RFC 2110 を厳密に読んだら確かに引用符が必要と解釈するのが自然な気もする。仕様書が曖昧なのが一番問題だな。
[31]
Mozilla Thunderbird
のフィードリーダー機能のメッセージでは、
エントリーの記事 (HTML) の URL
(引用符等のない絶対URLで)
が
Content-Base:
に設定されます。
(素片識別子付きのこともあります。)
[18] 適用範囲:
RFC 2110 には、Content-Base
と Content-Location
が適用されるのはその実体そのものだけであり、
multipart/*
の実体に指定しても内側の実体本体には適用されないと規定されています
RFC 2110 4.1。
が、それに反する例もあります RFC 2110 9.3。
Content-Location
の改訂版の RFC 2557
には相当する規定が無いので、撤回されたものと思われます。
[3] RFC 2110 (>>2)
をご覧下さい。
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 1808
で Base
欄として説明されているものです。
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
は実体本体中で再定義されるかもしれないことに注意して下さい。
[23] RFC 2616 は使われていないし導入するのも難しい、 MHTML とも仕様が微妙に違うため削除するとしています >>5, >>11。
[26] RFC 4229 は RFC 2068 を出典に IANA登録簿に登録しています >>24。 状態は「標準」となっていました >>24。
[27] 現在は RFC 2068 と RFC 2616 が出典となっており、 状態は「廃止済み」になっています >>25。
[12]
>>8-11 Mozilla (Not Classic Mozilla) 系 MUA (Mozilla Suite の MUA とか、 Thunderbird とか)
で非 local の文書を添付して送ると Content-Base
と
Content-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 が吐きまくっているみたいです。
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
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.
CFWS
が書けるというのには問題があります。(
が URI なのかcomment
なのか判断できないことがあります。詳しくはContent-Location:
欄の解説をご覧下さい。