Cookie:一般に流布している情報とRFCとのずれ

前提として

本文章は、多分に覚書の性質があります。情報に付いては可能な限り正確さを心がけたいと願ってはいるのですが、願いと現実には、時として乗り越えがたい隔たりが存在し得ます。
したがって、本文書を鵜呑みにせず、読者諸氏に置かれては可能な限り自分自身での検証をお願いしたく思います。

一般に流れている情報として

一般というものに対する定義は非常に難しいのですが、とりあえず「わりかし有名な検索エンジンで引っ掛けてきた複数のサイトの情報の最大公約数」程度の認識を持っていただければ、と思います。
さて。
概ね、以下のような文字列が、Cookieを食わせるさいには必要である、といわれています。

Set-Cookie: CookieData1=Test+Data; expires=Wed, 03-Apr-2002 00:00:00 GMT;

まぁ、実際にはこのほかにいくつかのオプションがあるのですが。ちなみに、オプションは以下のものがあるといわれています。

name=value: データの名前と、それに対応する値。これは必須です(valueはからでもいいんですけどね)。いくつかの文字「スペース、カンマ、セミコロン」が混入することを許されていないことから、大抵の場合URLエンコードがなされているようです。
expires=GMT値: 設定データの有効期限。明石標準時(日本で使われている一般的な時間)ではなく、世界標準時であるGMTが指定されています。
フォーマットは、「Wdy, DD-Mon-YYYY HH:MM:SS GMT」。ちなみに、曜日と月は、３文字の省略形が使われることが多いのですが、フルスペルで実装しているものもあります。
また、この値を過去の値にするとCookieの削除になり、設定しないと「ブラウザを閉じた時点で破棄される」一時的なCookieが作成できます。
domain=ドメイン名: このCookieが所属するドメインを指定します。そうすると、今後、このCookieは「所属するドメイン」でしか読めなくなります。まぁセキュリティー用ですね。
path=パス名: domainとほぼ同じで、これはドメイン以降の、pathに関する情報です。
secure: これは「書くか書かないか」というもので、いわゆる「名前=値」の書式ではありませんので要注意。
これが設定されると、セキュリティー的に保護された通信である場合(通常SSLとか)に限ってデータのやり取りを行います。
一部の「Cookieを解説しているサイト」では「Cookieは暗号化されてやり取りされます」と説明されています。

RFCでは？

さて。世間にはRFCというものがありまして。歴史的経緯その他の解説は別に譲るとしまして、簡単に言うと「ネットでのお約束事」が書いてある文書です。
とりあえず、ネットをある程度以上しっかり触るのであれば、一度は読んでおきたいものになります。で、CookieにまつわるRFC文書ですが。RFC2109ってのがありまして、ここに書いてあります。
原文はネットに転がりまくってますので、検索エンジンあたりで探してください。なお、英語が今一つ堪能でない方は、有志の方の邦訳も結構転がってますので適宜活用されることをお勧めします。でも、見比べながらでかまわないので、原文も読みましょう。
で。
RFC2109は、「February 1997」に書かれています。これだけ時間がたっていれば、ブラウザへの反映も問題ない…と思うのですが。
読めば読むほど、いわゆるWebで紹介されている「Cookie」とはかけ離れた実態が浮かび上がってきます。
さて。どんな感じなのでしょうか？
ちょいとばかし掻い摘んで、目に付いた「差分」を書き繕ってみたいと思います。

expiresが存在しない: 個人的にはとってもでっかく見える部分なんですが、どんなもんでしょ？
RFCの記述では「Max-Age」というものが用意されています。つまり、Cookie設定後、Max-Ageヘッダで指定した秒数だけ経過したらCookieを破棄するべきである、と書かれています（こっちのほうが設定楽なんだよなぁ）。
全てのvalue(＝の右側にある値)はtoken | quoted-stringである: 日本語で書くと「決まりきった文字列(トークン)か、或いはクォーテッドストリング（"で囲まれた文字列…厳密にはもう少し規約があるのですが－RFC822参照－)」であることが求められています。
また、クォーテッドストリングの中は、基本的に「エンコードとかはしない」事が想定されています。
つまり「CookieData1=Test+Data」は正しくなく、「CookieData1="Test Data"」と書く必要が出てくるわけですね(URLエンコードにおいて、'+'はスペースを示します)。
ちなみに、上記の書き方は「CookieData1 = "Test Data"」という風に、＝の前後に空白を認めることになります。
Cookieのname部分の先頭に＄を入れてはいけない: これはまぁどこにも「OK」とも書かれていないのですが。別用途で使用するため、＄が先頭にあってはいけないそうです。
Commentというヘッダがある: どうも今一つ用途が見えないのですが、文字通り「コメント」を入れることが出来るようです。
Versionというヘッダがある: しかもこれは「必須」（後の必須は「名前＝値」のみ）。
今回の文書に対するバージョンは１なので、「Version="1"」になるそうである。

他にもいくつかあるのですが、割合に大きいところで上記のようなものがあります。

ところが現実は........

実際に、上記の仕様でCookieを発行して使ってみましょう。特に気になるのが、CommentとMax-Age。
結果から記述すると、現存のブラウザのほとんどが対応していません（多分）。少なくとも、WindowsでIEの5.5、NNの4.76、6.02、Operaと試しまくってみたのですが、概ねペケです。

結論：或いはこの駄文が言いたかったことへの考察

RFCの仕様「のみ」を鵜呑みにして実装すると、結局「使い物にならない」モジュールが作成されてしまいます。
結論から言えば、現在も大抵のブラウザは「Netscape社の提案していたCookie」をベースに作られているのです。
しかし、それは「じゃぁRFCなんて気にしなくて今までどおりに作ってればいいジャン」という発言には、残念ながらつながりません。今後、ブラウザがどのように発展していくかがわからないからです。
そしてまた今一つ。「実装をベースに別の実装を作ってはならない」という話にも通じます。大抵のプロトコルはその根底に「理論」があり。RFCは、その中心の一つなのです、間違いなく。
余談ですが、一つ。某最大手のコンピュータソフトウェア会社は、えてしてこの規約を破る傾向にあります。しかし、世の大抵のソフトは、きちんと規約に沿って作成されているのです。この状態で（大手だしって事で）「いいじゃないか、その大手の規約に合わせれば」という話になってしまうと、それは極論から言えば「大手（のみ）が、一方的に押し付ける形で全てのプロトコルを決めることが出来る」状態になってしまいます（今一つ極論になってないのが怖いのですが）。
競争が可能な状態にするためにも、基本になる決まりごと「プロトコル」は、誰もが知っている、共有できるものである必要があるのです。「知らない」事と「知っているけどとりあえず実装していない」事には、獅子の子が落とされたらそのまま死しんでしまいそうなほど深い隔たりがあります。
その辺の「知識的啓蒙」とかいう高尚なものの、一助の万分の一にでも、本稿がお手伝いできるのであれば筆者望外の幸いです。

戻る　