WEBプログラミング NOW!

Lunascape とfavicon.ico

前回の「アタック？--アクセスログ謎のエントリーの原因（MSOffice/cltreq.aspや_vti_bin/owssvr.dllやSlurpConfirm404）」の続きのような話です。エラーログに大量出現するものの一つに「favicon.icoが見つからない（404エラー）」というものがあります。このfavicon.icoの存在をはじめて知った5年ぐらい前は非常に不気味に感じたものです。正体を知ればどうってことはないのですが・・・。

上のように、Firefoxなど対応ブラウザでアクセスすると、URLの頭に小さなアイコンが表示されます。また、お気に入りに登録した際に、上の画像のようにアイコンつきで登録されるため、目的のサイトが見つけやすくなるのです。そのため、大手のサイトではみんな、このfavicon（favorite + icon＝お気に入りアイコン）を利用しています。

利用の仕方は、そのサイトのルートディレクトリーにfavicon.icoという画像ファイルを置くことです。例えば、Yahoo! Japanなら、http://www.yahoo.co.jp/favicon.icoです。そのページのURLの階層がどんなに深くなって、例えば、http://dir.yahoo.co.jp/Computers_and_Internet/Security_and_Encryption/であっても、http://dir.yahoo.co.jp/Computers_and_Internet/Security_and_Encryption/favicon.icoは存在しなくていい。というより、存在しても意味がない。

ところが、エラーログを眺めていると、ルートディレクトリーにはちゃんとfavicon.icoを置いているのに、favicon.icoを含むURLが404エラーで、ログに大量出現していることがあります。なぜ？正直、このfavicon.icoは一インターネットユーザーとしては便利なことこの上ないのだが、数々のサイト（ドメイン）を管理するウェブマスターとしては非常に面倒な代物です。エラーログにfavicon.icoが大量出現するのが嫌で、適当に作成したfavicon.icoをアップしているぐらいなのに、それでもエラーログに残っています。

ルートディレクトリーではなく、HTMLファイルと同じディレクトリー内で毎回favicon.icoを探しまくっているユーザーエージェントが存在します。文字化けしているユーザーエージェント名も結構多いのですが、文字化けしていないもののその90%以上が「Luna」あるいは「Lunascape」というユーザーエージェント名でした。そこで早速、Lunascape最新版でテストしてみました。すると再現できました。また、ユーザーーエージェント名が文字化けする場合があることも確認できました。しかし、再現できないサイトもあります。

違いが何かと考えてみると、変なfavicon.icoの404エラーが発生するのは、Amazon Web Service+mod_rewriteで作成したサイトであることに気がつきました。でも、mod_rewriteを使っていないサイトでも起こるような起こらないような。mod_rewriteを使っているサイトは全部サブドメインを使っているからなのか。サブドメインを使っていることがLunascapeの不具合？を誘発しているのか？　また、はっきりとした結論は出ていないが、Lunascapeが状況によって、ルートディレクトリー以外のfavicon.icoを取得しようとすることがあることだけは確かである。もう少し、検証が必要そうです。

ただ、いくつかLunascape + favicon.icoの話題はGoogleでも発見できましたが、それほど話題にはなっていないようなので、もしかしたら私が利用しているWEBサーバの設定に問題があるのか、私の.htaccessの書き方などがまずいことなど他に原因があるのかもしれません。原因が分かり次第、また記事をアップします。

アタック？--アクセスログ謎のエントリーの原因（MSOffice/cltreq.aspや_vti_bin/owssvr.dllやSlurpConfirm404）

アクセスログ（エラーログ）を見ていると、謎のURLへのアクセスも結構あります。例えば、

/MSOffice/cltreq.asp?UL=1&ACT=4&BUILD=6254&STRMVER=4&CAPREQ=0
/_vti_bin/owssvr.dll?UL=1&ACT=4&BUILD=6254&STRMVER=4&CAPREQ=0

このMSOfficeと_vti_bin君のエラーログはたいていの場合、必ずと言って良いほど対（ペア）で記録されています。

このログは、MSOfficeと書いてある通り、マイクロソフト社のOffice製品をインストールしている場合で、ある条件に当てはまる場合に、アクセスしている人間（そのマイクロソフト社製品の利用者）が（多くの場合）意識していないところで自動でアクセスしています。そのある条件とは、Office製品で利用可能な「WEBディスカッション機能」です。「WEBディスカッション機能」の詳細や謎のリクエストの発生条件などは、下記のサイトをご参照ください。

●WEBディスカッション機能
http://obsidian.s53.xrea.com/archives/000509.html

結構、このアクセスは、アタックか何かと勘違いされやすいのですが、アタックではありません。だけど、かなり行儀の悪い仕様だと思います。

アクセスログの中で謎のエントリーは他にもたくさんあります。例えば、
SlurpConfirm404
の存在を見たことのあるかたもおられるでしょう。

どう考えても存在しないURLを何度もリクエストされ、気持ち悪いったらないのですが、これが実はユーザーエージェントが
Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp)
になっているので、さらに性質（たち）が悪いです。ホストアドレスはinktomisearch.comになっているし・・・。

Yahoo!がこんな馬鹿なことをするわけがないと先入観があると、余計に混乱し、不安になります。何かのアタックかと？ ユーザーエージェントの書き換えはいとも簡単にできたとしても、ホストアドレスの偽装容易ではないはずなのに・・・。PHPのgethostbyaddr関数の裏をつくような方法があるのかな・・・。

しかし、実際は、

●雑記帳/狼どもの熱き砂漠
http://www.twin.ne.jp/~akr_m/free/free

のサイトにも説明がありますように、Yahoo! helpの回答がこのへんてこなリクエストの回答のような気がします。

● 【Yahoo! Help】 Your crawler is asking for strange URLs that have never existed on my site, like /piopio/darkness-halo-bottom-camera.htm. Are you looking on the wrong host?
http://help.yahoo.com/help/us/ysearch/slurp/slurp-10.html

普通、ページが存在しない場合、404リスポンスヘッダーをサーバは返すべきですが、中にはHTTP 200 OK"を返すWEBサーバがあるために、そのサーバがどういう仕様なのかを調べるために、Yahoo!のロボットは、わざと存在しない（であろう）URLをリクエストして、反応を確かめているようです。

しかし、この英語の質問の中では、「/piopio/darkness-halo-bottom-camera.htm」という例示があるのですが、私が見るのは決まって、「SlurpConfirm404」なわけで、このexampleとしてのURLとは似ても似つきません。やはり、Yahoo!のロボットを装っているだけで別のユーザーエージェントなのか・・・、これは未だに確証が持てていません。

Konquerorで画像の入れ替えJavascriptで不具合が発生するケース

Konquerorというのは、Linuxのブラウザである。私が作成しているサイトでは、Linuxは非対応とうたっているので、Konquerorで表示がおかしくても問題ないといえば問題ないのですが（実際、統計的に見ても4千人に1人ぐらいしかアクセスしているユーザーはいません。）、最近はKnoppixなどでお気軽にLinuxが試せてしまいますので、お気軽にテストしたくなります。

最近、テストしていたら、不可解な現象が起きました。画像の入れ替えをJavascriptで行うことは結構あります。マウスを画像の上に載せると画像が切り替わるrollover（ロールオーバー）などが代表例ですね。Konquerorでは、特定の条件下では、画像がうまく切り替わらずに、元もとの画像Aの上に別の画像Bが描画されたり、全く切り替わりが起こらない現象が起こります。

※  最初、青色の画像だけが設置されたところに、ボタンをクリックするごとに、青色→黄色→青色→黄色→青色と変える単純なスクリプト（設置サンプル）でテストしてみました。青色の画像と黄色の画像のサイズ（widthやheight）は元々同一ではありません。合同ではありません。 本来、1回目のクリックで、青色の画像が消えて黄色の画像だけが表示されて欲しいのですが、Konquerorでは、青色の画像が残ったまま、黄色の画像がその上に描画されてしまう（本来、背景色の薄いピンクの模様にならなければならないところが元の青い画像のままで、再描画されていない、というのが正確な言い回し？）。 これは2枚の画像のサイズ（widthやheight）が異なることが根本的な原因ですが、当然（?）他のブラウザではこのような現象は発生しません。また、Konqueror（テストに使用したのは、Knoppixに付属のKonqueror3.4.2と3.3.1）では、「最初の1回目だけ」この現象が発生し、2回目以降ではこの現象が発生しません。つまり、Konquerorでは、青色→青色と黄色の混合→青色→黄色→青色と変化していきます。

結論から言いますと、Konquerorでは、KDE Bug Tracking Systemに報告されている「Bug 25317: javascript bug, image width wrong at first change (testcase) 」がまだ直っていないようです。

続きを読む "Konquerorで画像の入れ替えJavascriptで不具合が発生するケース"

MacIE+Tiger: getTime()で時間を正しく取得できない現象（キャッシュの影響が原因？）

<script>
s=1128679263484;
s3=(new Date()).getTime();
alert(eval((s3-s)/1000));
</script>

これは、ある基準値となる時間（ほぼ2005年10月7日19時1分3秒）からの経過時間（秒数）を求めるJavascriptである。1000で割っているのは、getTime()で得られる値が1970年1月1日から経過したミリセカンド（1秒=1,000ミリセカンド）だからだ。

この極めて単純なJavascriptもMacIE5.2.3（Tiger）では見事にバグります。MacIEで最初に表示させた場合には、他のブラウザ（SafariやFirefoxなど）での計算結果と同じなのですが、時間の経過とともにどんどんずれていきます。Macを起動したまま2日間置いた結果、30,000秒（=500分=8時間20分）以上の差が生じてしまいました。

原因ははっきりとは分かっていませんが、MacIEのキャッシュ機構と関係がありそうです。なぜなら、MacIEのキャッシュをクリアにした後、一旦MacIEを終了させ、もう一度MacIEを起動させてみたところ、30,000秒のずれはなくなっていました。（なお、MacIE5.2.3では、GMT=グリニッジ標準時での時間を返してしまうなどの不具合はありませんでした。）

ただ、一定時間で一定の狂いが生じるのかどうかは分かりません。少し観察した結果では違いました。例えば、1時間3,600秒を3,700秒のペースでy=ax的に比例して、誤差が広がっていくなら分かりやすいのですが、そうでもないようです。もしかたら、Macがスリープに入ると、誤差が急拡大するなどのパターンがあるのかもしれません。

また、キャッシュだからといって、数時間前にテストした際にgetTime()関数が返した値をまた返してくるとかいう現象ではなく、本来進んでいるべき時間よりも少ない時間（2日間の計測で約17%の誤差。）しかMacIEでは経過していないということなのです。MacIEだけ時間の流れの速さが違うというか、アインシュタインが喜びそうな現象（浦島太郎効果？）なのかもしれません（物理は全然分かりません。間違っている可能性大です）。

ただし、この現象がTigerでMacIEを使う場合のみ起こる現象なのか、Pantherでも起こるのか、あるいは、私のeMacでのみ起こる現象なのかは今のところ不明です。OS9.2.2のMacIE5.0では、この現象は起きませんでした。少しGoogleで調べてみただけですが、こちらに、MacによってgetTime()の返す値に違いがあることが少し触れられているだけでした。

MacIEでは、今回のことに限らず、キャッシュで悩まされることは多いので、キャッシュ原因説はかなり有望かもしれません。時間があるときに、Pantherなどで調べてみたり、どのような場合に誤差が広がりやすいのか研究してみたいと思います。

<<2005年10月10日午後9時44分追記>>
Panther+MacIE5.2.3(iMac (Graphite) M8492J/A)では、同じIE5.2.3でもこの不具合は発現することはないことが分かりました。やはり、Tigerとの組み合わせで起こるか、私のeMacの問題のようです。Tiger+eMac+MacIE5.2.3では、キャッシュをクリアした直後は正常な数値に戻りましたが、一晩寝かせて（スリープ状態で放置）、再びテストしてみると19,340秒も誤差が生じていました。実に5時間以上の誤差です。ただし、スリープ状態に入ることとgetTime()の誤差の関係は依然として不明です。

ブロードバンド時代にナローバンドに対応する方法（シミュレーション方法）

ブロードバンド時代と言われて久しい。総務省が発表した平成17年版　情報通信白書によれば、インターネット利用世帯に占めるブロードバンド利用世帯は62.0％と報告されています。

総務省の別の統計によれば、契約者数ベースでも、いわゆるブロードバンド人口は2,000万を超えています。そして、この増加の傾向はものすごいスピードで進行していることも事実です。しかし、同時に、フレッツISDNやモデムを使った接続（=ナローバンド）での接続も依然として多いことを、WEB製作者は忘れてはならないでしょう。

仮に3Mbpsぐらいの実測のADSLを使っているとしても、ISDNの理論値である64Kbpsの50倍ぐらい早いのである。これぐらい、ページにバナー広告や画像を貼り付けても大丈夫だと製作者は思っていても、万人がそうではないのである。約３分の１の方は、いまだにナローバンドを利用していることをWEB制作に携わるものは忘れてはならないであろう。

仮に、ページの総容量（画像を含む）が100KBのページを作ったとしても、64KのISDNなら、最速でも、100÷（64÷8）=12.5秒かかります。ブロードバンドに慣れると、100KBのページがどれぐらい重く感じるか分からなくなります。そこで、私はADSLとは別に、eo64というダイアルアップ接続の契約を敢えて行っています。

続きを読む "ブロードバンド時代にナローバンドに対応する方法（シミュレーション方法）"