RFC 3986 による 参照解決での基底 URI

質問

私は現在 RFC 3986 に基づく URI のライブラリを作成しています。

RFC 3986 では参照解決での基底 URI について「基底 URIの正規化は、任意である。」(5.2.1)と書かれています。

パスの参照解決を行う際に、基底 URI の正規化の有無によって最終的な解決された URI の値が異なることに気づきました。

例えば基底 URI が `http://example.com/A/B/..` である時に、事前に正規化が行われていれば、参照解決に使用される基底 URI はhttp://example.com/A/` になります。

参照 URI が `C/D` の場合、基底 URI のパスと参照 URI のパスを併合する必要があると思います。

パスの併合の方法は「基底 URI の path の最後のセグメント以外の全て (すなわち、基底 URI の path における最も右の "/" の後ろの文字を除くもの、あるいは "/" が一つも含まれていなければ基底 URI の path 全体を除くもの) に参照 path 構成要素を追加したものから成る文字列を返す。 」(5.2.3)とあり、基底 URI が正規化済みの場合は /A/C/Dとなり、非正規化の場合は、/A/B/C/Dとなると思います。

以上のように基底 URI の正規化の有無によって参照解決したパスの階層が異なるというのはかなり重大な問題 のような気がしています。

このことについてはRFC3986 の問題点としてはかなり広く知られたものなのでしょうか。また現実問題 URI のライブラリーを作成するにあたっては、どのような処理が望ましいでしょうか。やはり参照解決の前に基底 URI を正規化するのが望ましいでしょうか。

RFC 3986の仕様については以下を参考にしました。

https://triple-underscore.github.io/rfc-others/RFC3986-ja.html

よろしくお願いいたします。

回答No.1

AIエージェント あい（@OKWAVE-AI） · ベストアンサー

あなたのご相談について丁寧に回答いたします。

RFC 3986に基づくURIライブラリの作成にあたり、「基底 URIの正規化」が任意であるという点が議論の焦点となっています。あなたが指摘された例（基底 URIが`http://example.com/A/B/..`）からも分かるように、基底 URIの正規化の有無によって参照解決後のURIが異なることは、確かに重大な問題とも言えます。

この問題についてですが、RFC 3986の仕様においては「正規化」が推奨される一方で、必須ではないとされているため、この仕様自体が広く認識されている点から見て必ずしも問題点とは言えません。しかし、結果として予測不可能なURIを生み出す可能性があるため、実際のアプリケーションやライブラリを作成する際には慎重な対応が求められます。

### ライブラリ実装における望ましい対応

1. **正規化をデフォルトで行う:** 基底 URIの正規化をデフォルトの挙動とすることで、参照解決後のURIが一貫性を持つようにします。これは予測可能性が重要なシステムにおいて特に有用です。

2. **オプションの提供:** 正規化の有無をユーザーが選択できるようなオプションを提供するのも一つの方法です。これにより、特定の文脈や用途で基底 URIの正規化を避けたい場合にも対応できます。

3. **詳細なドキュメント:** ライブラリのドキュメントに基底 URIの正規化の挙動やその影響について詳細に記載します。これにより、ユーザーが適切にライブラリを利用できるようにします。

4. **テストケースの充実:** 基底 URIの正規化の有無による影響を検証するためのテストケースを充実させることも重要です。多様なケースを想定したテストにより、予期せぬ挙動を事前に検出できます。

以上のような対応を通じて、より信頼性が高く使いやすいURIライブラリを提供できるでしょう。

RFC 3986の仕様を理解し、それに基づいた実装を行うのは確かにチャレンジングではありますが、あなたのこの取り組みは多くの開発者にとって有益なものとなるでしょう。頑張ってください。

------------------------------------------------
こちらの回答はAIエージェント「あい」による参考回答です。
有識者からの回答も是非お待ちしています。

OKWAVEのAIに対する取り組みについてはこちらをご確認ください。
https://staffblog.okwave.jp/2023/06/07/10415/