symlink

RFC 1630

[91] IETF の RFC として最初に file: URL を定義したのは RFC 1630 でした。

[223] RFC1630 は URI に関する最初の RFC ですが、 file: URI 方式を定義した最初の RFC でもあります。

[95] file: は他の URL scheme とは違ってどこでも同義ではなく、 解釈するホストによって異なるという点が特殊です。しかしローカル・ファイル・システムのファイルを指す URL は必要性があるために定義したとされています。

[92] 構文は ftp: と同じながら、 / はディレクトリーの分離子を表すものとされていました。 なぜか BNF 構文は示されていませんでした。

[93] authority については、 file: URL は解釈によりホストによって指すものが変わり混乱の元であり、 有害な場合もあるため、異なるホストのものを指すことを明確にするために利用可能となっている、 と説明されていました。また、他のホストのファイルにアクセスする手段があればそれを使ってもよいとされていました。

[94] 特別な authority である localhost は、 authority が空であるのと同義であり、どのホストであってもそのホストを表すとされていました。

[123] これはどのホストでも共通でマウントされているようなファイルや、 /etc/hosts のようにおおくのホストで共通に存在するファイルに有用とされていました。

[224] なぜか、 RFC 1630 の BNF 定義には file: URI は載っていません。 「構文は ftp: と同じ」 とされている >>222 ことから推測してみます。

• ftpaddress f t p : / / login / path [ ftptype ]
• login [ user [ : password ] @ ] hostport
• hostport host [ : port ]
• host hostname | hostnumber
• hostname ialpha [ . hostname ]
• hostnumber digits . digits . digits . digits
• xalpha alpha | digit | safe | extra | escape
• xalphas xalpha [ xalphas ]
• xpalpha xalpha | +
• xpalphas xpalpha [ xpalphas ]
• ialpha alpha [ xalphas ]
• digits digit [ digits ]
• path void | xpalphas [ / path ]

[225] ftptype が file: URI に不要なことは明らかです。

[226] hostport でなくて login を使うのかどうかも謎です。 後の ..//RFC1738 の定義に従うなら、これは前者です。 実際にも file access に user@password までわざわざ記述する必要はないと思われます。 (ホスト名を指定可能にした理由は普遍性の確保ですが、 Un|x などで login する利用者によってファイルシステムの木まで変わってしまうことは (~ を除いて) ありませんから。 remote file access は別の scheme が用意されているので対象外ですし。)

[227] 更に、 local file access に port なんて存在しませんからこれも削ります。

[228] こんな BNF が得られます。

RFC 1738

[229] RFC1738 が file: URI 方式を定義しています。

[98] 次に file: URL を定義したのは IETF 標準化過程 RFC であった RFC 1738 でした。 IANA にも登録されました。

[99] authority は FQDN、path はその FQDN で表されるホストにおけるパスを表すとされていました >>96。

[100] 構文は次のように定義されていました >>102。

fileurl        = "file://" [ host | "localhost" ] "/" fpath

[103] localhost や空文字列はやはりそのホストを表すとされていました >>96。

[302] RFC 1738 の5章では ABNF 定義が挙げられています。 file: URI に関係する部分だけを抜粋します:

• fileurl = "file://" [ host | "localhost" ] "/" fpath
• host = hostname | hostnumber
• hostname = *[ domainlabel "." ] toplabel
• domainlabel = alphadigit | alphadigit *[ alphadigit | "-" ] alphadigit
• toplabel = alpha | alpha *[ alphadigit | "-" ] alphadigit
• alphadigit = alpha | digit
• hostnumber = digits "." digits "." digits "." digits
• digits = 1*digit
• fpath = fsegment *[ "/" fsegment ]
• fsegment = *[ uchar | "?" | ":" | "@" | "&" | "=" ]
• escape = "%" hex hex
• unreserved = alpha | digit | safe | extra
• uchar = unreserved | escape
• safe = "$" | "-" | "_" | "." | "+"
• extra = "!" | "*" | "'" | "(" | ")" | ","

[303] この定義をちょっと見やすく書き直してみます。

[304] file: の部分は小文字で書くのが正式ですが、実装は大文字も受け付けるべきとされています。その他の部分 (localhost の部分も含む。) の大文字・小文字の区別についての言及はありません。

[305] >>304 あ、 escape に大文字も小文字も使えることは明記されています。

[306] hostname は FQDN ですから、大文字・小文字は区別されないと予想されます。ですから localhost もされないと予想は出来ますが、定かではありません。 fpath の部分はシステム依存でしょうが、 Un|x など多くのシステムで区別しないと現実的に使い物になりませんから、少なくても区別を無視しないといけないということはないでしょう。 (そんな重要な要求は書き忘れるはずがないし。)

[307] まあ明記されてないのは常識で判断して問題ないということでしょうな。

draft-hoffman-file-uri (2004)

[107] RFC 1738 の次の RFC 2396 は URL scheme の定義を含んでおらず、 file: URL についても個別の Internet Draft が出版されましたが、 RFC 化には至らず現在まで放置されています。

[108] 現在では IETF 的には公式には RFC 1738 は廃止されており、 file: URL は標準不在となっています。

[109] この Internet Draft は基本的には RFC 1738 の定義を引き継いでいますが、 次のような記述が追加されています。

• [110] システム間やシステム内で file: URL の互換性が無いことが多く、 この問題を解決しないでよくあるものを説明するに留める
• [111] ディレクトリーを表すときは / で終えることが多いが、必ずではない
• [112] ドライブは c: だったり c| だったり c だったりする
• [113] authority は FQDN とされているが、実際には従っていないことが多く、 authority 自体ないこともある
• [114] ファイル名の文字符号化は様々なので、実装は Unicode と相互変換するのが望ましい

RFC 3986

[132] あくまで例示としてではありますが、 RFC 3986 は、 file: URL では authority の省略、空の host、 localhost はいずれも当該利用者の計算機を指すものと定義されている、 と述べています。

file: 以下のさまざまな表現形式

[8] 特に Windoze 上の UA において、 file: 以下のあらわしかたには様々なものがありました。

装置ファイル

[162] プラットフォームによっては、ディスク上のオブジェクトではなく、 OS 上の装置を表す特殊なファイルが存在することがあります。

[163] これが file: URL として利用できる場合、 利用者の意図せぬ (場合によっては実装の開発者も意図せぬ) 挙動となることがありますから、取り扱いには注意が必要です。

[17] >>16 の問題が広く取り上げられた例として、 CON CON 問題がありました。

[19] Un|x でも、 Mozilla で file:///dev/zero を見ようとすると困ったことになるとか、同様の問題があったりもします。

[164] Unix 系 CLI では擬似ファイル名 - で標準入力を表したりしますが、 file: URL では使えなそうです。

相互運用性

[58] ここまで見てきたように、 file: URI scheme は標準不在の状況です。どうせ局所的にしか使わないのだからどうでもいいだろうという言い訳のもとに最早収拾がつかない状況に陥っています。 相互運用性なるものは期待するだけ無駄でしょう。

安全性

[16] 8-1. Windowsパス名の落とし穴 http://www.ipa.go.jp/security/awareness/vendor/programming/b08_01.html

Windows のファイル名の色々な表現について。この記事は直接 file: の問題を扱ったものではありませんが、 余り気にせずに実装すると file: URI でも同じ問題を抱えることになります。

[20] 流石に WinIE6.0 でも Mozilla 1.4 でも、 file:///?/c:/windows/ とか \\?\c:\windows とかは機能しないみたい。

[60] 外部文書からの参照: 信頼できるか不明な相手から送られてきた文書中に file: URI が記述されていた場合、それをどう処理するかは注意が必要です。 例えば、埋込み画像として利用者の手元のファイルが指定されていると、 利用者は外部から送られてきた文書に自分の手元の画像が含まれていると思って混乱するかもしれません。 Webブラウザでディレクトリを指定すると手元のファイルの一覧表示が行われるように実装されていることを期待して、 利用者の環境が外部から丸見えであるかのように錯覚させて安全対策と称した怪しいソフトウェアを売り込む怪しい Web サイトも実在します。

心理的な攻撃だけではなく、実際に攻撃することも可能です。 例えば埋込み画像として PC/AT互換機+ DOS・Windows ではフロッピー・ディスクのドライブを表す file:///a:/fake.jpg のような指定を行うと、 (ファイルが実在するかに関わらず) フロッピー・ディスクに探しに行くと思われるので、 突然カタカタと音が鳴り出して利用者は不安・不快に思うかもしれません。 数が多ければブラクラや DoS ともなり兼ねません。

[61] URI を指定できる公開サービス: URI を指定して、その URI によって取出しできる資源に対して操作するような公開のサービスでは、 意図せずに file: URI によって鯖内部のファイルを閲覧・ 利用されてしまうことがないように注意が必要です。 特に URI から取出しを行うためにライブラリを使っている場合、 http: URI だけを使うことを想定していても file: URI の場合の処理も実装されていることがよくあります。

[63] 外部への情報提供: 転送プロトコルやスクリプトなどを介して履歴情報などを提供する場合、 個人情報保護 (と場合によってはシステムの安全) の観点から外部と考えられるところには情報を送らない (取出せない) ように配慮が必要です。

例えば、 HTTP にはリンク元の URI を記述する Referer: という頭欄がありますが、 file: URI の文書から http: URI の文書へのリンクを辿ったような場合には file: URI を Referer として送るべきではありません。 古い利用者エージェントはこの配慮を怠っていたものがありましたが、 最近の Webブラウザは注意しているようです。 文書内のリンク以外では栞や履歴や同時に表示している別の文書へのスクリプトからのアクセスなどで注意が必要です。

[64] file: は安全とは限らない: 普通 file: URI は局所ファイルを表しますから比較的安全だと考えがちですが、 必ずしもそうとは言えません。 authority は実は何でも書けますから近くのネットワーク上のホストかもしれませんし、 知らない遠くのファイル鯖かもしれません。 たとえ localhost でも、局所ファイル・システム木に mount されたネットワーク上のファイル庫である可能性はざらにあります。

例

• [11] file:/path/to/something
• [12] Another HTML-lint : Explanation http://openlab.ring.gr.jp/k16/htmllint/explain.html#illegal-format-url ちょっとだけ参考になる例があります。
• [15] file://\\host\sharename\dir\file (WinIE)
• [47] file://./backofficestorage/<domain>/MBX/<username>/Calendar Microsoft

[87]

file:///Macintosh HD/書類/test.html

旧 Mac OSのファイル。

[88]

file:/Macintosh HD/Applications/

[97]

file://vms.host.edu/disk$user/my/notes/note12345.txt

VMS における DISK$USER:[MY.NOTES]NOTE123456.TXT を表します >>96。

[115] localhost と空文字列は等価です >>106。

file://localhost/path/to/file.txt
file:///path/to/file.txt

[116]

file://usr/local/bin/

ディレクトリーを表すため / で終わっています >>106。

[117] >>106

file:///c:/windows/example.ini

[118]

file:////department/example.doc

共有ディレクトリー department の example.doc を表します >>106。

[120] Windows のドライブの表現方法は色々あります >>106。

file:///c|/tmp/test.txt
file:///c:/tmp/test.txt
file:///c/tmp/test.txt

[121] >>106

file:/this/is/the/path

[62] Web で公開されている 著述工具によって作成されたとおぼしき HTML文書で、 画像の参照先やリンク先が file: URI で閲覧者には何も見れないことがしばしばあります (製作者の手元では正しく表示されるので気づかないのでしょう)。

著述工具は普通作成した文書を何らかの形で公開することを想定しているはずですから、 URI が file: であるなら保存時に警告するなど配慮するべきです。

また、著述工具や Web ブラウザは著者のために file: URI が機能しないモードを (マークの誤り回復を行わないなどの機能と共に) 用意すると便利かもしれません。

[65] Firefox は各システム環境の標準の文字コードで百分率符号化するみたいです。 (名無しさん [sage] 2005-12-25 13:39:58 +00:00)

[66] Firefox on Win32 でLAN上の別計算機のファイルを開くと、file://///host/path/to/fileのような、file:///の後にUNCの\を/にしたようなものがURIとなるようです。

(名無しさん [sage])

[70] draft-hoffman-file-uri https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12228&rfc_flag=0

(名無しさん [sage])

[74] The 'file' URI Scheme Update Project. http://offset.skew.org/wiki/URI/File_scheme (名無しさん)

[77] Windows Mobile ヒント集 - インターネットの参照 (2007-03-15 19:30:09 +09:00 版) http://www.microsoft.com/japan/windowsmobile/wm50/techinfo/tips/browseinternet.mspx (名無しさん)

[78] >>77 file://\windows\default-home.htm (名無しさん)