もっと言ってしまえば、cgiの使えるサーバでなおかつLocationヘッダも出力できるなら、aタグのhref属性、cssの外部ファイル、JavaScriptの外部ファイル、とかもLocationヘッダを出力するcgiへのリンクにして、とにかく訪問者が自分のWebページ内で何をやったか全てを記録できてしまうんじゃないかと考えた。まぁここは実験室なんでそんなこともいいかなと。動作確認は取れていないけれどこんなところだろう。
open OUT,">>access.log";
print OUT join'',map{"$_ $ENV{$_}\n"}sort keys %ENV;
close OUT;
my %u = (
'Gif' => 'test_gif.gif',
'Index' => 'test_html.html',
'JavaScript' => 'test_js.js',
'CSS' => 'test_css.css'
);
if (defined $ARGV[0] && defined $u{$ARGV[0]}){
print "Location: $u{$ARGV[0]}";
} else {
print "Location: $u{Index}";
}
結論から言えば、上のスクリプトは自分の環境(isweb,Windows Me,Internet Exprorer 6.0)のもとでは期待通りの挙動を示す。実際にこのサイトにあるいくつかのファイルは上のようなアクセスログ取得cgiを噛ませてブラウザに取得させている(上と全く同じではない)。言い換えれば、あるHTMLファイルに中に上の4つのファイルへのリンクがあった場合、これらをcgiファイルと対応した引数で書き換えることで、元のHTMLファイルをブラウザで開いた場合と全く同じように見えるということだ。これが効果的なものかどうかを検証せねばならない。アクセスログが取れるという点を除けば全く効果的ではない。100個のHTMLファイルに同じスタイルシートを適応した場合、このスタイルシートに向けてリンクが張られる。スタイルを変更する場合は現在適応されているスタイルシートを直接編集すればよいのであって、わざわざ上のようにして変更するメリットはないだろう。これは、JavaScriptや画像ファイルについても同様である。
上のようなスクリプトを介して実際のコンテンツに訪問者を誘導することは、HTMLファイルに含まれるimgタグ、scriptタグ、metaタグ、のような訪問者の許可無しにリンク先の内容をダウンロードさせるタグの回数だけcgiが呼び出されることになる。サーバーの仕事は2倍になるわけで、特にHTTP/1.0のConection: closeでコンテンツをダウンロードさせるようなブラウザを使っている場合、サーバに高負荷をかけることになるかもしれない
それでもなおメリットを探すとすれば、多少の取りこぼしはあるものの、サーバに記録されるのと同じようなアクセスログが取れるという点だろう。まともな解析を行えば、画像、JavaScript、スタイルシート、これらを訪問者がどのように処理しているかもおおよそのところわかる。例えば、あるHTMLファイル中に含まれるリンク(aタグのhref属性にはcgiを指定)を辿って別のHTMLファイルに移動し、移動先のHTMLファイルに画像(imgタグ)、JavaScript(scriptタグ)、スタイルシート(metaタグ)、をcgiを指定して仕込んでおいた場合、非常に短い時間間隔で同一のIPアドレスから4回cgiにアクセスがあれば、訪問者は画像、JavaScript、スタイルシート、を全て許可していることになる。
iswebが提供しているアクセス解析のログ保存期間は確か3ヶ月程度だと思ったが、このcgiスクリプトを噛ませると、ディスクスペースの許す限りアクセスログの保存ができる。上の例では環境変数をログファイルに保存するだけだが、例えばここでApacheのアクセスログと同じフォーマットを適応させれば、世の中に数多く存在するApacheのアクセス解析ソフトにアクセスログを読み込ませることができる。