要約

  • 2000年10月のRFC 2965は新旧Cookieの共存を設計した。両方を理解するクライアントは必要に応じて旧式のCookieを送り、さらにCookie2: $Version="1"で新版への対応を示す。対応するサーバーはSet-Cookie2へ進み、古いサーバーは合図を無視できた。
  • 新しい応答には、Cookieを返すポートを絞るPort属性や、利用者に説明を示すCommentURLを付けられた。対応表明、サーバーの新版応答、利用者による説明の確認はそれぞれ別の段階である。
  • 2011年4月のRFC 6265はRFC 2965を置き換え、歴史的な文書へ移すよう求め、Cookie2とSet-Cookie2を廃止した。実際に使われるCookieとSet-Cookieを規定し、同じホストのCookieがポートをまたいで共有されることも明記した。

ブラウザーが新しい言葉の名札を出す

HTTPの要求は一回ずつ独立していても、店の買い物かごや読書の続きは複数の要求をまたぐ。サーバーがCookieを渡し、ブラウザーが適用できる値を次の要求で返す。1997年2月のRFC 2109は、この状態交換を早い時期に文書化した。次の難題は、既に使われているクライアントとサーバーを壊さずに規則を改めることだった。Web全体のプログラムを一斉に更新する管理者はいない。

2000年10月のRFC 2965は二つの追加ヘッダーで道を開こうとした。サーバーの新版応答がSet-Cookie2、クライアントの能力表明がCookie2である。新旧両方を理解するブラウザーは、古いSet-Cookieから受け取った値については従来の形式でCookieを送り続ける。同時にCookie2: $Version="1"を添え、自分なら新版も分かると知らせる。

サーバーも新方式を理解すれば、その後のセッションではSet-Cookie2を送るべきだとされた。知らないサーバーはCookie2を無視すればよい。旧式のやり取りはそのまま続く。新しいブラウザーが先に進む意思を示しても、古いサーバーを門前払いにしない設計だった。

三つのヘッダーの仕事は異なる。Cookie2は能力の宣言で、保存した状態値をまとめて運ぶ容器ではない。Set-Cookie2はサーバーからブラウザーに新版の値と属性を渡す。後の要求で適用可能な値を返すのはCookieだ。記録に能力宣言が一つ見えたとしても、サーバーが新版で答えたか、その値が後で戻ったかは続くメッセージで確かめる必要がある。

合図と結果を分けることは、この歴史の要点でもある。規格には「こう答えるべきだ」と書ける。実際のサーバーがその枝へ進んだかどうかは別の記録である。設計書に描かれた移行経路は、現場の要求と応答が通って初めて道路になる。

新しいレーンに用意されたもの

名前の末尾に「2」を付けただけではなかった。Set-Cookie2のPort属性は、Cookieが後で返される範囲を絞れた。属性を省けば、関係するホストのどのポートにも返せる。値を付けずにPortと書けば、受け取った要求のポートだけに限られる。ポート番号を列挙すれば、その一覧だけを許す。同じ機械で複数のサービスを動かす運営者には、状態値の行き先をより細かく指定する手段となる。

CommentURLには別の狙いがあった。Cookieの用途を説明する情報をサーバーから示し、短いコメントよりも詳しい説明や複数言語を載せられるページへ案内する。利用者が理解するための窓を作る発想だ。URLを示すことと、利用者が実際にページを読んで判断することは、それぞれ別の出来事である。

こうした機能が働くには、ブラウザーが合図を出し、サーバーが新版応答を選び、双方がその属性を扱わなくてはならない。対応する片側だけでは、狭いポート範囲も説明ページも旧式の会話に現れない。優れた仕様があっても、参加者の組み合わせが揃わなければ利点は書類の中に残る。

共存規則は細かかった。Set-Cookie2を知らない古いクライアントは従来のCookieで動く。両方を扱うクライアントは、値がどちらの応答ヘッダーから来たかを区別し、適切な形で返す。同等のCookieに旧式と新版の応答が並んだ場合は、新版を優先する。旧世界を守るための移行は、新しいプログラムに二系統の実装と試験を求めた。

この二つのRFCは、何台のブラウザーがCookie2を送ったか、どれだけのサーバーがSet-Cookie2を返したかを数えていない。採用の細かな年表には、日付付きの実装記録や実際の通信が必要だ。ただし公式文書だけで、2000年の提案と2011年の規範上の結末は追える。

2011年、標準は別の道を選ぶ

2011年4月のRFC 6265は、インターネットで実際に用いられるCookieとSet-Cookieを記述すると宣言した。序文では、以前のNetscapeの説明、RFC 2109、RFC 2965は現実の使われ方を十分に表していなかったと述べる。サーバーには整った生成方法を勧め、クライアントには既存サーバーの多様な出力を受け止める処理を求めた。新しい規格は走っている車を見て交通規則を書いた。

同じ序文はRFC 2109とRFC 2965を歴史的な扱いへ移すことを求め、RFC 2965を置き換え、Cookie2とSet-Cookie2を廃止した。ヘッダーの登録欄でも両者は廃止と記される。能力を掲げる札と、それに応じる新版の出入口は、中心的なCookie契約から外れた。普段使いのCookieとSet-Cookieが残った。

2011年の文章は残った仕組みを礼賛していない。同じホストのCookieが異なるポートの間で共有されることを、問題の一つとして挙げる。ブラウザーの同一オリジン規則は通常ポートの違いを区別する。2000年のPort属性が扱おうとした境界はここにある。それでも後の標準は、版付きのポート制御を中心へ戻すのではなく、既に流通する交換を記述した。

この転換を「名前の競争」と片づけると事情が見えなくなる。サーバーは新版の応答を選べるが、ブラウザーの能力宣言を作れない。ブラウザーは自分の要求を変えられるが、古いサーバーに新版を理解させられない。2000年の仕様は、その分散した選択を丁寧な互換規則で包んだ。2011年の仕様は、実際に共通語になっていた交換を中心に据えた。

文書上の結末は明白である。RFC 2965は置き換えられ、二つのヘッダーは廃止された。個々のブラウザーがいつ対応したか、いつ外したかは別途実装の記録をたどる必要がある。標準の方向転換そのものには、2000年と2011年の原文が残っている。

予備の道に住人が残った

Cookie2の移行案は乱暴ではなかった。新版に対応するクライアントが先に名乗り、対応するサーバーが応じ、古い相手はいつもの会話を続ける。互換性を守る設計である。同時に新版の利益は、各組み合わせの両端が移行して初めて得られる。サーバーはブラウザーを待ち、ブラウザーはサーバーを待てた。

2011年の選択には具体的な代償があった。細かいPortの返送範囲と、説明を示すCommentURLの標準経路は、廃止される側の枝に残った。生き残ったCookie交換にはポートをまたぐ共有などの弱点があり、後の文書もそれを認めている。現実に使われない改良は、文章の上でどれほど整っていてもネットワークの性質を変えない。

互換のために残した旧経路は、やがて一時的な逃げ道ではなく本線になり得る。Cookie2は新しい道の入口で名札を掲げた。11年後、標準はその名札を棚に収め、人々が通っていた入口を記録した。