_
有休取って今日もお休み。
_
北山崎。崖が険しすぎるので、このへんはなんともない。
鵜の巣断崖。よく見ると奥の方に復旧工事をやってるクレーンが写ってる。
浄土ヶ浜。さすがに海面に近いと傷跡を見せつけられる。
_
ということで、帰路は北東北の太平洋沿岸部を走る国道45号をひたすら南下。震災後に東北方面には何度も(遊びに)行ってるけど、内陸ばっかりで海の方はあえて避けていた。半年たって、そろそろいいかな、と。ただの野次馬だろと言われればまさにその通りで返す言葉はないんだけど、これまで何度も来たところがどんなふうに変わってしまったのか、今のうちにどうしても見ておきたかった。
_
もちろん報道で知ってはいたけど、実際目にすると、ひどい。津波にやられたところが更地になってるのであればまだよかった。コンクリートの基礎だけはしっかりと残ってるから、そこに生活の場があったことをどうしても想像せざるをえない。さらに、土地があったはずのところが水没してるのを見ると、もう溜息しか出ない。陸前高田では R45 は海から数百メートルは奥を通っていて、道路から海なんか見えなかったはずなのに、今は道路脇がすぐ海。高田松原の松が1本を残してすべて倒されたなんてニュースは事実じゃなかった。高田松原は松どころか地面ごと波にさらわれて消えていた。
_
工事のトラックは多かったけど、まだどこも完全な復興計画はできてないし、瓦礫の撤去も済んでないところもあるので、整地や道路工事ばっかりで新しい建物を建てるというのはどこも手つかずのようだ。そんな中、小さなプレハブ小屋に不釣り合いな大きな花輪に「祝開店」とあったパーマ屋さんを見かけたときには涙腺が崩壊した。たくさんの人が亡くなった場所でこんなことを言うのもなんだけど、これからどんな新しい街ができていくのかが楽しみになった。たぶんこれからも何度も足を運ぶけど、そのたびごとに新しい姿が見られるだろう。その最初の一歩を見ることができただけでも、野次馬しにいったのは間違いじゃなかったと思う。写真は上に出したような観光地以外では1枚も撮ってないので手元に記録は残ってないけど、記憶しておけばいいや。
_
蛇足。本州最東端とどヶ崎に向かう途中。津波で舗装のひっぺがされた道に小さめの岩がかくれていて、車の下をこすってしまう。こすっただけならよかったんだけど、ラジエーターに穴が開いて冷却液が漏れ出した(泣)。大丈夫かしらんと思いつつそのまま走ってたら、案の定2時間ぐらい後になって温度警告灯が点滅をはじめた。車に乗るようになってはじめてのオーバーヒート。穴が開いたといってもダダ漏れというわけではなくゆっくりしたたる程度だったので、数時間ごとに水を注ぎ足す程度の応急措置でなんとか帰ってこれたけど、はじめはどうなることかと途方にくれた。修理代いくらかかるんだろう。
_
cookie の規格は4つある。廃止されたものもあるけど、新しいものが廃止された古いものの完全上位互換になっていればいいのに微妙に互換性がないのが困ったところ。
- Netscape
- Netscape による最初の規格にして事実上の標準。RFC になってないどころか本来の URL が消滅して web.archive.org に頼らざるをえないものがデファクトスタンダードになってるのが泣ける。
- Set-Cookie/Cookie。
- RFC2109
- 最初の RFC。obsoleted で historical。
- Netscape と同じ Set-Cookie/Cookie だが、Netscape 規格には存在しなかった version 属性が必須なことで識別可。
- version 属性以外にも異なる部分が多く、互換性は低い。
- RFC2965
- 次の RFC。obsoleted で historical。
- Set-Cookie2/Cookie2 でそもそもヘッダ名からして違う。RFC2109 で version 属性ができたんだから version=2 とでもしておけばよかったのに。
- まったく新しいヘッダを導入したわけなので RFC2109 と容易に共存できるはずなんだけど、共存せず 2109 は obsoleted になった。
- まあ、Netscape と RFC2109 が互換性がないのに同じ名前で併存してるのが紛らわしいということで、普及に失敗した RFC2109 を撤回するのが主目的の RFC だったんだと思う。
- RFC6265
- Set-Cookie/Cookie に戻った。version 属性は存在しない(オプションですらない)ので、ぱっと見では Netscape 規格とは区別がつかない。netscape にない属性(max-age など)が使われている場合のみ識別可能。
- Netscape 仕様を完全に置き替えることを狙ったと思われるもので、わりと互換性が高いが、異なる挙動を要求するところが一部にあって完全互換ではない。
- いちおう現行規格だが、今年4月に発行されたばかりなのでこれに準拠した実装が広まってるとは考えない方がいい。
ひどく迷走してる。まあ、いろいろあるけど、version 属性のついた cookie とか Set-Cookie2 とかはまったく普及してなくてまず見ないし、RFC6265 はまだ発行されて日が浅いので、世間で使われてる cookie の 99% はいちばん最初の Netscape 仕様のものだと思っていい(というか、RFC 準拠のものを使ってる例ってあるの？)。さらに状況を複雑にしてるのが、Netscape 仕様がいろいろよろしくないところが多いためにブラウザは100% 準拠せずてきとーに拡張したり制限を加えたりして使ってるってこと。これ、明文化されてないので、よくわからん。RFC6265 は内容からして旧来の RFC の改訂版というより、むしろよくわからん Netscape 仕様(改)を文書化したものと考えた方がいい内容なんでわりと馴染みやすいけど、前述のとおり微妙に互換性がなく、どっちに従うべきなのか判断に迷うところがある。
_
で、
domain 属性だけど、Netscape 規格ではこう書いてある。
The default value of domain is the host name of the server which generated the cookie response.
domain のデフォルト値はサーバ名だよ(無指定だからといってサブドメインに対する動作を変えるなんてことはないよ)ってことなので、example.com というサーバから
Set-Cookie: SESS1=F3B435;
という応答が帰ってきた場合は、
Set-Cookie: SESS1=F3B435; Domain=example.com;
と同じとみなされ、サブドメインにも送る。domain 属性を指定しない方が安全、ということはない。指定してもしなくても同じ。Netscape 規格に忠実に従っているのであれば、という注釈つきだけど。RFC6265 では確かに domain 指定がなかったらそのホストのみに送れ(サブドメインには送るな)と異なる動作を要求してるけど、上のような Set-Cookie の使い方では Netscape と RFC6265 のどっちに従うべきか判断できない(RFC2109、2965 でないことは判断できる)。
こちらでは IE と i モードが RFC に従っていないとあるけど、デファクトスタンダードの Netscape 規格には正しく従った動作なので、これを責めるのは酷だろう。ってゆーか、RFC6265 以降で i モード新機種ってどんだけ出た？ RFC6265 の方に従ってるように見える実装も、意図して RFC6265 に準拠したのではなく、独自に仕様をいじった結果として気がついたら RFC と同じになっていた、という程度なんじゃないかと思う(根拠なし)。
_
Netscape 規格がデファクトスタンダードなんだけど、それで不十分なところをブラウザ側で独自に制限を追加している例をいくつか挙げておく。
_
まさに cross domain cookie injection の対策に関する部分。こう書いてある。
Only hosts within the specified domain can set a cookie for a domain and domains must have at least two (2) or three (3) periods in them to prevent domains of the form: ".com", ".edu", and "va.us". Any domain that fails within one of the seven special top level domains listed below only require two periods. Any other domain requires at least three. The seven special top level domains are: "COM", "EDU", "NET", "ORG", "GOV", "MIL", and "INT".
ダサい。クソ。あまりにクソなので、これを忠実に実装してるブラウザは今ではほとんどない(まったくないわけではないが。w3m とか)。public suffix list はこのクソをある程度まともに使えるようにするものだけど、クソである理由の本質的なところには何ひとつ手をつけてないので、やっぱりクソ。ドメインの階層構造はそのドメインの管理主体を規定しないし、ドメインの管理主体が web コンテンツの管理主体と一致するという保証はどこにもないのに、それが一致するという前提で仕様を設計してるというのがそもそもの間違いなので、ここを直さないかぎりは何をやってもクソ。たしかに一致している例は多いので、一致しているとみなすのが蓋然性の高い推定であるのは事実だけど、どこまでいっても推定にしかすぎないのもまた事実。public suffix list なんてやっつけな対応ではなく、cookie の送信を許可するサイトを明示的に指定できるようにもっと根本的に仕様を見直さないとダメ。
_
Netscape 仕様への非準拠もうひとつ。
（Pathの）「末尾には / を付けるようにする」というのも変です。CookieのRFCにはこんな説明はありませんし、RFCで例示されているPath属性の例にも、末尾の / はありません。おそらく、Path=/fooと指定したCookieが /foobar というディレクトリにも送信されることを懸念しての指示だと思いますが、無用な懸念です。
実際のところたいていのブラウザはそのように実装されてるんじゃないかと思うけど、Netscape 仕様には
The path "/foo" would match "/foobar" and "/foo/bar.html".
と明記されており、これに厳密に従うなら /foobar にも送られるのが正解。つまり、大部分の実装は Netscape 規格にあるとおりには動作していない。ただ、Netscape に忠実な実装が存在する可能性は否定できないので、path=/foo/ とするのは無用な懸念ではないだろう。妥当な配慮だと思う。
_
Internet のいろんな規格はとりあえず最新の RFC に従っておけばいいことが多いんだけど、こと cookie に関していえばそれは間違い。広く使われているのは RFC ではない文書にてきとーなアレンジを加えた明文化されていないナニモノか。わけわからんけど、残念ながらそれが実情。将来的には RFC6265 がその立場にとってかわることになるんだろうけれど、せっかく策定した RFC を完全にシカトした前歴が2回もあるので実際はどうなるんだか。少なくとも現時点では、Netscape 規格と RFC6265 で仕様が矛盾している箇所において、たった半年前に発行されたばかりの RFC に従った挙動になっていないからバグだ、と非難するのは適当ではないだろう(5年たってもまだ改まってないなら非難していいと思うけど)。仕様に互換性がないのを承知した上で、どちらでも安全に動くような方策を考えるべき。
_
ま、わしゃ RFC6265 もダメだと思ってるけど。