HTMLからシンボリックリンクのCSSやJSを読み込む動作がIEとGoogle Chromeで違う。
例えば以下の構成だったとする。
SymLinkCSSTest.html
└─real_path
├─syml_test.css
├─syml_test.js
├─<SYMLINK> syml_test_from_real_path.css [syml_test.css]
└─<SYMLINK> syml_test_from_real_path.js [syml_test.js]
つまり実態は「syml_test.～」で、
そいつをシンボリックリンクで参照している「syml_test_from_real_path.～」というファイルが同階層に存在している。
このときの動作をまとめると
ファイルブラウザ(Version)結果Google Chrome(36.0.1985.125 m)読める（JS実行できる）
| syml_test.css | IE(10.0.9200.17028) | 読める（スタイル適用される） |
| Google Chrome(36.0.1985.125 m) | 読める（スタイル適用される） | |
| syml_test.js | IE(10.0.9200.17028) | 読める（JS実行できる） |
| syml_test_from_real_path.css | IE(10.0.9200.17028) | 読める（スタイル適用される） |
| Google Chrome(36.0.1985.125 m) | 読めない（スタイル適用されない） | |
| syml_test_from_real_path.js | IE(10.0.9200.17028) | 読める（JS実行できる） |
| Google Chrome(36.0.1985.125 m) | 読めない（JS実行できない） |
となる。
実態パスのCSSやJSが読めるのは当然だが（まとめてて変な気がしてきたｗ）、
シンボリックリンクのCSSやJSはGoogle Chromeでは読んでくれない。
別のケースを考える。今度はフォルダごとシンボリックリンクにしてみる。
SymLinkFolderCSSTest.html
└─<SYMLINKD> syml_path [real_path]
├─syml_test.css
├─syml_test.js
├─<SYMLINK> syml_test_from_real_path.css [syml_test.css]
└─<SYMLINK> syml_test_from_real_path.js [syml_test.js]
このケースでは先ほどのテストで使ったCSSやJSの実態が入ってるフォルダ「real_path」自体を
シンボリックリンクフォルダ「syml_path」を経由して参照する形になる。
この結果は以下の通り。
ファイルブラウザ(Version)結果
| syml_test.css | IE(10.0.9200.17028) | 読める（スタイル適用される） |
| Google Chrome(36.0.1985.125 m) | 読める（スタイル適用される） | |
| syml_test.js | IE(10.0.9200.17028) | 読める（JS実行できる） |
| Google Chrome(36.0.1985.125 m) | 読める（JS実行できる） | |
| syml_test_from_real_path.css | IE(10.0.9200.17028) | 読める（スタイル適用される） |
| Google Chrome(36.0.1985.125 m) | 読めない（スタイル適用されない） | |
| syml_test_from_real_path.js | IE(10.0.9200.17028) | 読める（JS実行できる） |
| Google Chrome(36.0.1985.125 m) | 読めない（JS実行できない） |
やっぱりGoogle Chromeではシンボリックリンクが見えない。
ただCSSやJSの入っているフォルダがシンボリックリンクになっても、
その配下にあるファイルそのものが元の方で実体ファイルなら読めるらしい。
どうもフォルダではなくファイルがシンボリックリンクになることに対応していないようだ。
ところでリンクはどうなんだろう。
単純リンクでつながるのかどうか、動きを検証してみる。
まずは最初のケース。
SymLinkCSSTest.html
└─real_path
├─aaa.txt
└─<SYMLINK> zzz.txt [aaa.txt]
で、やると↓のようになった。
ファイルブラウザ(Version)結果Google Chrome(36.0.1985.125 m)移動できない
| aaa.txt | IE(10.0.9200.17028) | 移動可能 |
| Google Chrome(36.0.1985.125 m) | 移動可能 | |
| zzz.txt | IE(10.0.9200.17028) | 移動可能 |
ここでいう「移動できない」はいわゆるNot Foundではなく、空白のページが表示される形を指す。
ちょうどIEのホームページ設定で「空白のページ」を設定したときの動きに見た目は似ている。
ファイル中身の情報があったとしても読み込めないという意味である。
WEBアプリケーションの静的コンテンツとして動作させた時の挙動は
これとはまた別になるのだろう。（404とかになるんだろーか？）
同様にフォルダごとシンボリックリンクになるケースを検証する。
SymLinkCSSTest.html
└─<SYMLINKD> syml_path [real_path]
├─aaa.txt
└─<SYMLINK> zzz.txt [aaa.txt]
で、やると↓のようになった。
ファイルブラウザ(Version)結果Google Chrome(36.0.1985.125 m)移動できない
| aaa.txt | IE(10.0.9200.17028) | 移動可能 |
| Google Chrome(36.0.1985.125 m) | 移動可能 | |
| zzz.txt | IE(10.0.9200.17028) | 移動可能 |
う～ん、やっぱりGoogle Chromeはファイルのシンボリックリンクには対応していないようだな。
他ブラウザまでは試していないが、SafariはシンボリックリンクファイルのCSSやJSは読み込めてそうだった。
正直シンボリックリンクをわざわざ読み込む要件が絶対必要かと問われると微妙な気もするが、
IEは比較的この辺の考慮が緩い（あまり深く考えてない様子が見受けられる）ようではある。
試していないが、恐らく画像でも同じことが起きるのだろう。
埋め込み式（iframe）の動画や音楽なども同様だろうか？
実態がファイルだとすると同じ結果になる気がする。
”意図せず別の場所に貼られたシンボリックリンクから覗けない”という意図があるのであれば、
悪意のある違法ダウンロードなどに対抗できる手段として有効ではありそうだ。
（そんな方法で外にDLさせようとするやついるのかな…）
この検証の事の発端は、
tomcatで特定のWEBアプリAの一部設定ファイルを
別のWEBアプリBに対するシンボリックリンクで構成しようとしたとき、
うまくいかないところからはじまった。
どうやらtomcat Ver4以降でシンボリックリンクを使う場合は
下記の個別設定をserver.xmlに書き込まないと動かないらしい
<Context path="/test" docBase="test" reloadable="true"> <Resources className="org.apache.naming.resources.FileDirContext" allowLinking="true"/> </Context>
が、これはtomcatの設定の話であって上記のブラウザ別の検証とはまた全然別である。
要するにここから端を発して興味本位で検証してみたというのが本意なのである。
上に少し書いたような、WEBアプリケーションとしての挙動は
単純にHTMLを表示するだけの動きとはまた変わるのだろう。
面倒だかららやないけど、複数のブラウザに対応したサイトを作成する際には
多少意識しておかなければなるまい。
