_ 特定サイトから直リンクされた画像を一発でウンコの画像にする方法。301 でリダイレクトすんのはマズいんじゃね？ 302 じゃないと。
_ あと、この方法だと、ブラウザやプロクシにキャッシュされそうな。いったんキャッシュされると、それが消えるまでの間はもともとの想定どおりでのアクセスでも正しい画像ではなくうんこ画像が見えてしまう。
_ うんこ画像がキャッシュされないように Cache-Control: をてきとーにいじるか、あるいは referer によって応答がかわることを明示するために Vary: Referer を返すかしないといけない。HTTP の仕様としては Vary を使うのが正しいんだろうけど、これだと異なる referer でアクセスされるたびに異なるキャッシュが生成されて無駄が大きいし、そもそも Vary に対応してないクライアントも存在するし、Vary に対応しててもヘッダごとにキャッシュするのではなく単純にキャッシュしないようになるというだけの実装も多いので、だったらはじめから Cache-Control で制御した方がはやいかもしれない。
_ 昼ごろ起きてきたら雪が積もってておどろいた。積もってるといってもせいぜい 1cm かそこらだけど、陽が高くなってるのに日陰だとまったく解けてない。道路は中途半端に解けた後で再凍結した感じで、いちばんスリップしやすい状態だな。このあたりでも毎年1回2回ぐらいは雪が降るけど、5cm 積もった後ならともかく、たったこれっぽっちの雪が昼過ぎまで消えずに残ってるというのはあんまり記憶がないなぁ。
_ 内容はまあ同意なんでとくに言うことはなし。一般のお客さんの理解が覚束ないのはしかたないかなとは思うけど、DNS の運用を請け負う業者が平気でこういうことを言うのはまじ勘弁してください。
_ このへん。
でもTTLを無視して古いキャッシュを持ちつづけるキャッシュサーバがそんなにたくさんあるのでしょうか。具体例があればぜひ教えてください。うーん、キャッシュ「サーバ」かどうかはわかんないけど、一定数は確実に存在してるね。コンテンツサーバ側はその1からその4まですべて問題ないと自信を持っていえる状況であっても見つかる。_ ただ、こちらはクライアントが名前解決にどんなプロダクトを使ってるかなんてわからんので、具体的にどれがそうなのかわからんのだな。JavaMail の API にいったん名前解決すると TTL を無視してプロセスが死ぬまでキャッシュするものがある、というのが何年もかかって唯一の確認できた例かな。
_ これ以外では、POP サーバのログを見てると、なんかのメーラーが同じように TTL を無視してキャッシュしてるらしき挙動が観測される。NAT 越しに接続してくる同じ IP アドレスの別アカウントの人はちゃんと DNS の変更に追随してたので、たぶん DNS サーバの問題ではなく、クライアントの問題。
_ IE とか firefox とかのよくあるふつーの User-Agent でサーバ切り替え前の古いサーバにアクセスしてくるものがいる、ってのは、やっぱりブラウザではなく DNS サーバがおかしいんだろうなぁ。家庭用ルータの DNS forwarder はかなりビミョーな動作をするものが多いようなので、腐れキャッシュもあるんだろうなーと推測されるけど、実際に確認したわけでなし。
_ ちうことで、コンテンツサーバの設定ミス、運用ミスがなくても古いキャッシュが使われてしまう例はありますよ、ということで。具体的にはやっぱりよくわからんので詳しいことを知ってる人がいたらだれか教えてください。
_ …あー、そういえば、TTL を無視してキャッシュするわけじゃないけど、ついこの間とある商用キャッシュ DNS で TTL の扱いがびみょーなものがあったな。TTL=0 のレコード(すなわち、いっさいキャッシュしちゃいけないもの)を ANY で問い合わせたときの応答が、なんというか、その、おかしいと断言まではできないんだけど、でも、なんかおかしかった。
_ そして本日、予定どおり jp の DNSSEC がはじまった。ちゃんと ad フラグが立ってるね。
% dig www.jprs.jp +dnssec ; <<>> DiG 9.6.0-APPLE-P2 <<>> www.jprs.jp +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6914 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 11 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;www.jprs.jp. IN A ;; ANSWER SECTION: www.jprs.jp. 86348 IN A 202.11.16.167 www.jprs.jp. 86348 IN RRSIG A 8 3 86400 20110213001655 20110114001655 32889 jprs.jp. UmcrZteEUGQxNiJFnAEmD8XzPo6wE5mYZ74MRPZy9ObUfmNQADISS7vP q3qXAIotB5ldz6Oy2lKlpgO9gOsObhwGxfo2ossrxTHs8l4G7+ljtkUO 4TbYA3PVRbyTQmCTS21n0gSq14yS3mjKwbzDPfRLJbcLdvZZgJHanwJ7 ebA= (以下略)
_ 00123 というゼロパディングされている文字列の頭のゼロを消すために、sh の arithmetic expansion を使って、
とした。$n が文字列ではなく数値として評価されて、n=123 になるはずだった。n=00123 n=$(($n))_ …… n=83 になった。$(()) の中では、ゼロからはじまる数値は8進数として扱われることを忘れていた。正しい書き方(の例のひとつ):
n=`expr $n + 0`_ bash だと、
で強制的に10進数と解釈させることができるんだけど、bash でしか使えな(以下略n=$((10#$n)