前回、試しにインターネットの昔話をしてみたのですが、どうも評判がいまいち
だったので、今回は昔話はちょっとおいといて、またいつものようにWebの技術
的な豆知識について書いていこうと思います。
URLを打つ作業というのは、特に初心者にとって非常に面倒で苦痛な作業です。
そこで、多くのWebサーバーでは、この作業を少しでも短くできるように、
例えば
http://web296.com/mailmg/index.html
といったURLを、
http://web296.com/mailing/
と省略する事が可能になっています。実際にこの省略は大変広く使われていて便
利なものです。さて、ここで最後のスラッシュも省略するとどうなるでしょうか?
http://web296.com/mailing
実際にクリックしてみると分かりますが、これでもちゃんとメルマガ登録のペー
ジが表示されます。しかし、この省略は実は間違いであり、しかもWebサーバー
や通信回線にとって、通常よりも多くの負荷がかかってしまうのです。今回はこ
の省略の是非と、その理由についてご紹介します。
さて、なぜ最後のスラッシュを省略すると負荷が掛かってしまうのでしょうか？
これはURLの表記法に理由があります。
URLは、おおざっぱに言って、
http://ホスト記述部/パス記述部
のような形になっています。上記の場合だと、「mailing/index.html」が「パス
記述部」です。そしてさらにこのパス記述部は、ファイルとディレクトリの階層
構造を示すために、
ディレクトリ名ディレクトリ名...ファイル名 (*)ディレクトリ名は０個以上い
くつでも可。ファイル名は省略可
という表記を取り、ディレクトリ名の末尾には必ずスラッシュがつく事になって
います。つまり、上記の場合、「mailing/」がディレクトリ名、「index.html」
がファイル名になるわけです。スラッシュは、ディレクトリ名やファイル名の区
切りではなく、「ディレクトリ名の一部」と見てください。
ここでおわかりかと思いますが、上記のように http://web296.com/mailing の
ように最後のスラッシュを省略してしまうと、mailingはディレクトリ名ではな
くファイル名と見なされてしまうのです。
しかし実際には、一般的なOSのファイルシステムの場合、ディレクトリ名と同名
のファイルは、同じ階層に存在できないことになっています。そこでほとんどの
Webサーバーでは、例えばmalingというファイルの要求があり、そこにmailing/
というディレクトリがあれば、おせっかいにも
「それって多分http://web296.com/mailing/の事だと思うから、もう一度アクセ
スしてね」
という返答をブラウザに返すのです（もちろん画面には表示されませんが）。こ
の返答を受け取ったブラウザは、URLを訂正して、再度Webサーバーにリクエスト
を出すわけです。これが負荷増大の理屈です。
では、よく見かける
http://web296.com
のようなスラッシュの省略も間違いなのでしょうか? これは以上のスラッシュの
省略とは事情がすこし異なります。ホスト記述部の直後のスラッシュは、上記で
も「http://ホスト記述部/パス記述部」と説明した通り、単なる「ホスト記述部
とパス記述部の区切り」であり、ディレクトリ名の一部ではありません。そして、
RFCではパス記述部が空の場合、このスラッシュは省略しても良いことになって
います。ですから、上記の http://web296.com のようにホスト記述部の直後の
スラッシュは省略しても全く構わないのです。
もっとも現在では、Webサーバーの処理能力も回線の太さも、昔に比べるとけた
違いに大きくなっているので、実はあまり負荷に関しては気にする事はありませ
んが、「ディレクトリ名の末尾のスラッシュを省略するのは本来間違っている」
ということは覚えておいて損はないでしょう。