インターネットなこと: 2011年1月アーカイブ

いやあ、今日も数時間を無駄にすごしてしまった。この糞忙しいのに・・・である。

今日引っかかってたのは「キャッシュ」の問題。
まあ、Web システムを開発している人は、何度かハマったことがあるんじゃなかろうか？
「ソースを直したのに相変わらず表示が変だなぁ。直し方が悪いんかなあ？」って思ってたら、単にブラウザが古い画面をキャッシュしてただけだった・・・っていうアレである。

本当にがっくりくるよな、あれは。
しかも、Firefox と InternetExplorer でキャッシュする条件が違ってたりして。
そもそも、更新日付が変わってたらキャッシュなんか見ちゃ駄目だろう？なのに、FFにしてもIEにしても、何か積極的に・・・つーか、サーバ上のコンテンツが更新されてるかどうかなんてろくすっぽ確認もせずにキャッシュ見にいくよな。鬱陶しい。
今時のブラウザは If-Modified-Since って聞かないの？

もう、インターネットの基盤だって整備が進み、回線速度だって上がってる今日この頃。「キャッシュするのが基本」って設計思想がもう間違ってないか？
つーかさあ、少なくとも If-Modified-Since は投げようよ。

実際のところ、最近のIEなんかは、どうしてもキャッシュさせたくない時は、「URL を変えてしまう」しか方法がないのだ。

例えば、不定期に更新される設定ファイルを FLASH 内から読みたい時。
設定ファイルの URL が http://exsample.com/hogehoge.txt だったとする。

ActionScript 3 で、

var loader:URLLoader = new URLLoader();
loader.dataFormat = URLLoaderDataFormat.TEXT;
var header:URLRequestHeader = new URLRequestHeader("pragma", "no-cache");

loader.addEventListener(Event.COMPLETE, completeReadUrlList);
loader.addEventListener(IOErrorEvent.IO_ERROR, onIOErrorReadUrlList);
loader.addEventListener(SecurityErrorEvent.SECURITY_ERROR, onSecurityErrorReadUrlList);

var req:URLRequest = new URLRequest("http://exsample.com/hogehoge.txt");
req.requestHeaders.push(header);

loader.load(req);

なんて書いて、この処理を Timer で一定時間毎に実行したとしても、IE では「FLASH をリロードするまで hogehoge.txt の再読込はしない」し、Firefox ではもっと酷くて「ページキャッシュを消去してからリロードするまで再読込はしない」のだ。マジ、意味わかんねえ、酷い話だ。hogehoge.txt の更新日時は当然変わっているのに・・・だぞ。(^^;
ローカルキャッシュがあったら、If-Modified-Since を含んだ http リクエストすら投げてないってことか？

しょうがないので、こういう時は、

var req:URLRequest = new URLRequest("http://exsample.com/hogehoge.txt?a=" + (new Date).time);

みたいに URL のケツにエポックタイムとか、そういうユニークな数字等をつけて、「こいつはキャッシュされてる URL じゃないよお」とブラウザを「欺す」しかないのである。

ActionScript 3 のエポックタイムはミリ秒単位なので、例えば上記の例だと、

http://exsample.com/hogehoge.txt?a=1296452293572

みたいな URL になるね。10秒後に同じ処理をおこなうと、今度は

http://exsample.com/hogehoge.txt?a=1296452303572

という URL になる。数字のところが変わってくるので、これは別のページと判断され、ブラウザはキャッシュを使わないのだ。ちなみに、? 以降の文字列はサーバ上の環境変数としてセットされるが、テキストファイルのような固定コンテンツでは無視されるだけである。なので問題無し。

いやあ、でも、これってダミーの文字列を含んだキャッシュがローカルにどんどん作られていくので、あんま好きではないんだよな、こういうやり方。
で、何とかならんかと、色々リクエストヘッダを追加してみたり、サーバ側でラッパー CGI カマしてみたりしたんだけど・・・駄目だった(^^;無駄な時間をすごしただけだった(^^;

なんなの、もう！（怒）

ほんま、更新日付だけはちゃんとチェックしてくれよ。その上で「更新日付が古ければ」キャッシュを使ってくれよ。それって、ブラウザの最低限の仕事じゃねえのかよ！？＞Firefox, InternetExplorer

Adobe AIRアプリから、某WebServiceのAPIをSOAP通信で叩くのだが、APIのエンドポイントにはBasic認証がかかってる。

ということで、エンドポイントへのアクセス時にヘッダに Basic 認証用の Authorization 情報を追加してやらんといかん。

具体的には、HTTP ヘッダに、

Authorization: Basic [Base64エンコードされた user:pass]

という情報を付けてやるのだが、もちろんいちいちヘッダ文字列の編集をしなくても、WebService クラスを使ってアクセスするのであれば、httpHeaders プロパティにセットしてやればいい。

    var encoder : Base64Encoder = new mx.utils.Base64Encoder();
    encoder.encode("ID文字列:パスワード文字列");
    ws.httpHeaders = {Authorization:"Basic " + encoder.toString()};

    ws.getHogehoge("");

みたいな感じ。
（URLRequest クラスでは requestHeaders だけど、WebService では httpHeaders。それに、requestHeaders は配列型だけど、httpHeaders は Object 型なんだね～）

どうも最近、俺は何もしてないのに Facebook に Youtube の動画がリンクされちゃう。
しかも、何か異常な数。色々な動画が...ってわけではなく、一つの動画が何回もリンクされるのだ。気持ち悪っ！

で、その動画も何か怪しいんだ。例えば「自作のマリオっぽいステージのゲームを自分にやらせてみた」とか。（笑）

実は最初にこういう現象が起きた時に、2ch記事のまとめ系ブログを見てたりしたんで(^^;、何か変なスクリプトでも踏んだかなっと思って色々調べてみたけどPCに異常はない。
何か気持ち悪いけど、Facebookの「友達」に「なんじゃ、こんなに怪しいゲーム系の動画ばかりチェックして」と変に思われるだけなんで放置してた（笑）

・・・が、やっと原因がわかったよ。
息子達（特に次男坊）が YouTube をチェックした時に発生しているのだ。

昨日、やわらか戦車系の動画２本が勝手に俺の Facebook にリンクされたのだが、その前に次男坊がやわらか戦車の動画を見たという話をしていたのだ。
で、試しに「お前、マリオっぽい妙に難しいゲームの動画とかも見たやろ？」と聞くと、やっぱ見てたよ、「自作のマリオっぽいステージのゲームを自分にやらせてみた」動画（笑）

どうも、YouTube で「評価する」ボタンを押して動画を評価すると、「www.youtube.com で高く評価しました」というリンクが Facebook に作られるようじゃね(^^;
全ての動画ではなく、息子がチェックした動画のうちのいくつかがリンクされているようなので、それらの動画を次男坊が高く評価したのだろう。
確かに、YouTube の動画見ながら笑い転げてるもんなあ。(^^;

まあ、これで原因がはっきりした。
しかし、次男坊も YouTube で動画を検索して見れるほどには情報リテラシーがアップしてきたか。それそろアクセス制限も考えないといかんな(^^;