2005-07-19

相対URIの解決方法

先日掲載したOperaの相対URIの解決方法に疑問の続き、疑問解決編です。

コンテントネゴシエーション [CONNEG] を使用した本サイトのリモートサーバのHTTPヘッダをよく確認したところ、Content-Locationの値がネゴシエーションで一致したファイルのパスになっていました。私がうっかりしてました。

つまり、先日記載したOperaの相対URIの解決方法は [RFC2616] に適応した妥当な方法と言えます。そしてそれは、多くのブラウザはこれに適応していない(HTTPヘッダの内容を判断していない)ことに改めて気付きました。まさか、Mozilla!?お前もか・・・。

前回と重複しますが、ユーザエージェントがXHTML/HTMLのリンク及び参照の相対URIを解決する際には、[HTML4] に記載の Resolving relative URIs [引用: http://www.w3.org/TR/1999/REC-html401-19991224/struct/links.html#resolving-relative-uris より] で解説されている方法で判断されます。例えば、http://a/b/c/d というURIの当該資源にbase要素を含まないならば、サーバによって形成されるHTTPヘッダの内容(Content-Location)を基に基本URIの情報を得ることが適います。

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

The value of Content-Location also defines the base URI for the entity.

[引用: [RFC2616] Hypertext Transfer Protocol -- HTTP/1.1 より]

前記した http://a/b/c/d というURIの基本URIが http://a/b/c/d.xhtml ならば、当該資源中のa要素のhref属性値が #s のみの場合でも、絶対URIはhttp://a/b/c/d.xhtml#s と解決することができます。

つまり、相対URIは得られた基本URIの情報を基にはじめて絶対URIとして解釈できるのです。

然しながら、現段階でどれほどのUAや検証サービス等がこのような解釈方法を行っているのか?私に知る由もありません。

注釈

  • [XHTML2.0-WD] では、HTMLのbase要素に変わり [XMLBASE] を使用します。
  • RDF/XMLは、[INFOSET]に従って、[XMLBASE] に対応しています。
  • サーバは Content-Location を供給するべきSHOULD)です。用語SHOULD等は、[KEYWORDS] で定義されているように解釈されます。
  • Content-Location が相対URIであるならば、相対URIは Request-URI と比較して絶対URIを解釈します。

本サイトの資源提供方法については、本サイトの手法についてに記載しています。