たまにしか会わないけれど、会うたびに名前が変わってる人がいたとしたらどうだろう。どの名前で呼んでいいのかとまどってしまわないだろうか。
「モーニング娘。」「藤岡弘、」「つのだ☆ひろ」みたいに名前に変な文字が混入してる人はどうだろう。「つのだ☆ひろ」「つのだ・ひろ」「つのだ♪ひろ」は同一人物だろうか違う人物だろうか。有名人ならともかく、マイナーな名前であれば記号の種類や混入位置なんてイチイチ覚えてられない。
人間であれば多少は融通が効く。しかし相手がコンピュータだとしたら？コンピュータというのは基本的に馬鹿である。馬鹿というか馬鹿正直だ。
人間であれば名前が変わっていても風体や声などでなんとなく同一視できるだろうし、たとえすぐにわからなくても会話などして記憶をたどることができれば、別の名前になってても「あぁ、ひょっとして○○さん？」などと把握できるかもしれない。
でもコンピュータ相手であれば「○○さんと××さんは同一人物」「名前の末尾に『さん』がついててたらそれは無視して比較してみれ」みたいなルールを教えこまないといけない。
また、「☆はあってもなくてもいいし、別の記号でもいいよ」「最後の句読点は無視して比べてみてね」みたいなルールも必要だろう。
こんな融通の効かないコンピュータを扱う時は、名前の細かな違いってやつには充分注意をしなくてはいけない。ちょっとした名前の綴りの違いがやっかいな事態を引きおこしかねないのだ。
あと、命名にも注意したい。「悪魔ちゃん」なんて命名して大騒ぎになった事件を覚えているだろうか?
URL
URLについて注目してみよう。インターネットはもはや珍しいものではなく、あちこちでURLを目にする機会が増えた。前世紀の話であるが、筆者が仕事でアメリカに行ったとき、とあるトイレに駆けこんだ。そこで驚いたのは、トイレの壁に張られていた宣伝チラシに書かれていたURLである。コンピュータ雑誌の記事とかならともかく、こんなところにまでURLが書かれるようになったのか、というアメリカの状況に驚いたのだ。しかしいつのまにやら日本においてもそのような状況は珍しいものではない。
そんなURLであるが、実際にウェブにアクセスしてみてとまどうことは多い。
自動生成のURLをそのまま使ってしまう
いちいちHTMLを書いていくのは面倒なので、なにがしかのウェブアプリケーションを使い、ページの管理を容易にする、というのは良いアイデアである。ただそのようなウェブアプリケーションを使う場合はURLに気をつけてほしい。
例) 変なトップページの URL
http://www.example.co.jp/ にアクセスしてみると、いつのまにやらhttp://www.example.co.jp/all みたいに、変な文字列が余計に増殖していることはないだろうか。
また、http://www.jp.example.com/ にアクセスしてみたら、http://www1.jp.example.com/content/default.aspx?c=jp&l=jp&s=gen などという呪文みたいなページになっていることはないだろうか。
トップページって http://www.example.co.jp/ みたいにドメイン名の直後に'/' が一つだけ、って思わない?
例) 呪文のようなURL
前述のトップページに限らず、サイト内の特定のページが変な文字列になってることは多い。たとえば、筆者の出身地の交通局の「概要」のページのURLは次のようになっている。どうやら自動生成されているものをそのまま外に露出してしまっているようだ。
http://www.example.jp/koutuu.nsf/1bdf7493ee7ae73249256732004b1eb8/a58cefa411659a9b4925672f0049ff4f?OpenDocument
せめて、
http://www.example.jp/koutuu/gaiyou
みたいにカスタマイズできないものだろうか。
綴りミス
Google で inurl:ivent や inurl:rink で検索してみよう。いずれも「イベント」や「リンク」のスペルミスである。正しくは「event」や「link」だ。ローマ字ですらない。
URLを付ける時は辞書を引くなり、あるいは割り切ってローマ字を使ってしまおう。多少、前述の「呪文のようなURL」に抵触しなくもないけど、数桁の数字にしてしまう、なんて手もある。筆者が関わってる某ページでは、名前付けで悩んだり恥をさらすくらいなら、とか、口頭で伝えやすい、という理由で、ある種のページのURLのパス名の部分はは3桁の数字と '.html' の組み合わせにしてしまっている。
実装手段を主張するURL
Wikiの普及に従って目に付くのであるが、URLの一部に、wiki.cgi みたいなのがくっついているページが非常に多くなってきた。
http://example.jp/wiki.cgi?Hoge
みたいなのならともかく、
http://example.jp/cgi-bin/wiki.cgi?page=Hoge
みたくなってくると無闇に長い。Wikiの開発元など、Wikiそのものを宣伝としているページであるとか、誰でも書きかえられるというWikiの利点を最大限に宣伝したいようなページならともかく、ウェブのメンテナンスが便利なツールとしてWikiを使っているようなところであれば、それがWikiであるかどうか、なんてことはページの作成者以外には関係のないことだ。そのページを見にくる人にとっては、それがWikiであるかなんてどうでもいい。
「Wiki」の部分はPHPだろうとJava Servletだろうと同じだ。PHPからJSPに乗りかえたり、JSPからASPに乗りかえたりするようなことが将来にわたって無いことは保証できるだろうか。
URL中に/cgi-bin/というのが無くたってCGIは設置できるし、拡張子は必須じゃない。
「どういう手段で実装されているのか」をURLという限られたスペースの中で主張する必要性はないのだ。普通の静的なHTMLのページの拡張子として一般的な .html や .htm なんてのすら邪魔だ。将来は静的ではなく、動的なページになるかもしれない。あるいはServer Side Includeを使いたくなるかもしれない。拡張子なんて不要なのだ。Apache であれば mod_negotiation を使えば、
http://example.jp/products
みたいに拡張子が無いURLであっても、DocumentRoot に products.html があれば、Apacheのほうで良きにはからってくれて、products.htmlが表示される。
名前の衝突
これは普段は気が付きにくいのだけれども、example.jp の Document Root にhoge.html というファイルと、hoge というディレクトリが併存していていて、hoge ディレクトリの中には index.html が置かれているとしよう。その場合、http://example.jp/hoge というリクエストでは何が表示されるだろう。hoge.html なのか、hoge/index.html なのか。
これは mod_negotiation が使われるよう、設定されているかどうか、mod_dir が設定されているかどうか、なんてことに依存するのだ。状況によりhttp://example.jp/hoge.html と同等の内容が表示されたり、http://example.jp/hoge/ にリダイレクトされて http://example.jp/hoge/index.htmlと同等の内容が表示されたりする。
mod_dir の罠
前項にもかかわってくることであるが、あるディレクトリの名前そのものをURLの末尾に指定した場合、ディレクトリ名の末尾に '/' が自動的に補完されて、そのディレクトリ内にある index.html が表示されたり、あるいはディレクトリの内容一覧が表示されたりすることが多い。しかしそれは前項の例のとおり、必ずしも真ではない。'/' の有る無しってのは軽々しく考えるべきではないのだ。
せせこましいと思うかもしれないけど、'/' が自動的に補完される、というのはウェブサーバとブラウザの間で余計なやりとりが発生しているのだ。その分、サーバやネットワークの負荷を上げる要因が一つ増えてしまう。負荷が洒落にならないようなサーバを運用している時は、そのあたりに注意したい。
いろんなホスト名
http://www.example.jp/ http://example.jp/ http://ns.example.jp/
が同じ内容のページ、なんて経験はないだろうか。何も考えずにDNSやApacheを設定すると、このようになることはありがちである。ただ一つの内容に複数の名前というのは余計な混乱の元になる。この例であれば、たとえば、http://example.jp/ が正しい名前であり、あとは別名、みたいに考えるのであれば、
NameVirtualHost * <VirtualHost *> ServerName example.jp DocumentRoot /var/www </VirtualHost> <VirtualHost *> ServerName www.example.jp ServerAlias ns.example.jp Redirect / http://example.jp/ </VirtualHost>
みたいにして、正規の名前以外でアクセスが来たら example.jp に飛ばす、といった設定をすると良いだろう。
いろんなパス名
どうしても、という理由で、同じドメイン内でページを移動しなくてならない、なんてことが発生するかもしれない。そんな場合、シンボリックリンクでごまかすのではなく、Redirect ディレクティブを使って元のURLへのアクセスは新しいURLに飛ばす、みたいな設定はしたほうがいいだろう。さもなければいつまでたっても古いURLへのアクセスは減らない。
CGI生成のページのURLの曖昧性
CGIに与えたパラメータにより、生成されるページの内容が変わる、なんてのは珍しくない。しかしここで嫌なことがある。たとえば、
http://example.jp/cgi-bin/display.cgi?page=Main&lang=ja http://example.jp/cgi-bin/display.cgi?lang=ja&page=Main
の2つのように、パラメータの順番が変わっても生成されるページが同じになることは多い。さらにはパラメータには「デフォルト」があって
http://example.jp/cgi-bin/display.cgi
みたいに、何もパラメータを与えなくても、最初の2つのURLと同じページになるように作ってあるところもあるだろう。
ある程度「わかっている」人であれば、これらのURLの文字列を睨めば同じ内容であることを字面から推測できる。しかし普通の人はどうだろう。
CGIのGETの使用には慎重でありたい。
mod_rewriteは万能ではない
これまで述べてきたことについては、Apacheの魔窟であるmod_rewriteを駆使すればだいぶん解消することは多い。しかし、CGIなどが生成するHTMLの「中身」まではタッチしてくれない。適当なフィルタを作って、Apache2の output filter機能などを使うなどしないと、HTML内のリンクは変なURLを指したままだ。
じゃあコードを書きよう、ってんでコードの中身を覗いてみると、「表示したい内容」という概念的なものから、実URLへのマッピングがプログラムコードのあちことに分散していることが実に多い。3つ程度ならいいけど、ある程度の規模になってくると、とても潰せない。
プログラムを作る場合に注意したいのは
- 「実URLから表示内容へのマッピング」
- 「表示内容から実URLへのマッピング」
を処理する場所をなるべく狭い範囲に閉じこめてしまうようにしたい、ということだ。
最近はなんらかのフレームワークを使って手軽にウェブアプリを構築することが増えており、このようなマッピング処理はウェブアプリの製作者がそれほど意識しなくてもいいことが増えてはいるが、そのようなフレームワークが生成するURLは得てして醜悪である。たぶんバリバリに使いこんでカスタマイズすればURLも綺麗になるのかもしれないけど、たいていへのイントロダクションではそこまで触れられていない。
さいごに
いろいろと並べてきてみたが、いかがであろうか。具体的な解決策については詳しくは触れてないので、実装は簡単では無いものも入っているだろう。実際、現状のApacheやウェブアプリのフレームワークでは、ここまで述べてきたことをすべて満たすのはわりと面倒である。
また、これらのことを実現するにはそれなりに実装に複雑性が導入されかねないので、そこが穴になる可能性もある。でもなんとかしたいと思わない？
初出
「日本Apacheユーザ会(仮)通信 vol.5」
(2004.12.30 コミックマーケット 67)