_ あけましておめでとうございます。今年の目標。
そんなかんじでてきとーでゆるゆるにやっていこうと思います。そんなわけで今年もよろしく。
- 自分じゃなくてもできることは他の人にまかせる。
- 自分じゃできない難しいことは無理せず他の人にがんばってもらう。
- 自分でやるときはカンタンなことでもさも難しいかのように演じて恩を売る。
_ 年明け早々から生活リズムが乱れっぱなしであかんわ。寝る。
_ 昨年（といっても1週間前だが）の 「“おとりマシン”で受信したメールの87％はスパム」---McAfeeという記事。これ、spam が 87% だった、という調査じゃないよね。ハニーポットに届いたメールを調べてみたら 13% がウィルスとかトロイとかだった（だから残りの 83% は spam だ）という調査だよね。 原文でもそう書かれている。
_ ソースは忘れたんだけど、spammer が anti-spam 製品ベンダのハニーポットのアドレスをつきとめ、そこにまともな文面のメールを送りつけて spam サンプルの収集を妨害している、という話があるらしいんだよね。いや、それだって spam には違いないので「87% が spam」という結果にウソはないんだけど、通常の spam とは性質の異なる攪乱用メールがその 87% の中にある程度の割合で含まれている可能性は考慮しておく必要がある（あるいはまったく含まれていないかもしれないけど）。今回のは McAfee による調査だけど、Symantec の Brightmail のようなハニーポットによる収集を核にしたしくみではこれは慎重に取り扱わなきゃいけない問題だったりする。このような中身はまともな文面のサンプル収集を妨害する目的のメールをほかの spam と同じように扱ってしまって、一般ユーザに提供する spam フィルタで spam として判定してしまうと、これは false positive につながることになるので。
_ まあ、そういうベンダの関係者でもなければまったく気にする必要のない話だが。
_ へー、買われちゃうのか。 Bonded Sender Programも IronPort がやってたんだけど、いつのまにか別の企業に売却されてたんだよね。経営やばかったんかな。
_ まあ、あそこの製品を使ってるわけじゃないから別にどうでもいいんだけど、 SenderBaseはなくしたりしないでそのまま続けてほしいなぁ。アヤしいホストを調べるのに便利なので。それだけお願い。お願いしても誰も聞いちゃいないけど。
_ はぁ？ なんかおかしな実験してるぞ、と思って手元で追試。
_ ……なんだこりゃぁぁっ。CGI が Last-Modified を返すと、Apache が勝手にクライアントからの If-Modified-Since と比較して 200 を 304 に変えちゃうよ。それって昔からそういう動作だったっけ？ そういうふうに動作すると明記したドキュメントってどっかにある？ ETag と If-None-Match の比較はしないようだけど、このように CGI が自前で Status: 304 を吐かないかぎりはサーバ側で勝手に応答をいじらず 200 を返すのが一般的な挙動。
_ CGI/1.1の仕様ではそのように応答をいじるべしともいじってもいいとも規定していないはず（しちゃいけないという規定もないはず）。なぜ Apache で親切にもそういう実装になっているんだろ。サーバ側で CGI の出力を改変してクライアントに返すことが禁止されているわけじゃないけど（というか、Status: とか Location: とかがヘッダに含まれていたら適切に改変せにゃならん）、conditional request に対して CGI の出力の 200 をサーバで 304 に変えるのがあたりまえだと思うのは間違い。CGI は NCSA HTTPd のころに規定された 仕様が今でもそのまま使われているが、その当時には HTTP/1.1 なんてものはなかった。If-Modified-Since とか If-None-Match のような HTTP/1.1 で導入された conditional request のことを想定しているはずがない。
_ CGI なんてのはクライアントからは見えず、サーバの中だけで完結することなので、仕様がどうなっていてもクライアントに影響が出ないかぎりは Apache 依存の親切機能に頼っても何の問題もない。304 にならない原因を CGI ではなく Apache に求めて、極端には Apache の方をいじって仕様を拡張してしてしまうのも解決策としてはアリだろう。だけど、その CGI をもしも Apache 以外の HTTPd の実装でも動かすことも考慮しているのならば、conditional request の処理はサーバ側の機能に頼らず CGI が自前でがんばらなきゃダメ。CGI/1.1 にはそんなことは規定されていないんだから、どんなサーバでも同じようにやってくれると期待してはいけない。だから、
ETag を入れると 304 が返らなくなるのは、 tDiary というより Web サーバ (Apache) の問題っぽい。というのはおかしい。問題なんてものは存在しておらず、あるとすれば Apache がやりもしないことをやってくれるという思い違いが存在していただけ。_ (1/10 訂正) ごめん。If-Modified-Since の方は HTTP/1.0 からあった。論旨は変わらんけど。