要約

  • marketplaceMCIは1994年、Webリクエストをまたいで注文、請求、配送の情報を保つ必要があった。MCIはNetscapeの当初のサーバー側保存案を退け、クライアント側への保存を求めた。
  • Netscapeはその要件を一般的なブラウザー機能にした。サーバーが状態値を送り、ブラウザーが後続の対象リクエストで返す仕組みである。その値だけでは、ブラウザーを操作する人が誰かは証明できない。
  • 1997年のRFC 2109は、すでに実装と互換性に形づくられた仕組みの標準化を試みた。利用者の制御、値の可読性、通信時の保護がないことも、規則の中で認識していた。

買い物かごが「忘れるプロトコル」を製品課題にした

Webの典型的な要求と応答には、実務上の抜けがあった。HTTPリクエストは資源を求め、レスポンスを受け取る。しかし次のリクエストに、アプリケーションがそれまでに積み上げた履歴が自動で付いてくるわけではない。販売側のサーバーに履歴を置く方法はあるが、その場合は状態管理に加え、ブラウザーが去った後に残る記録も扱わなければならない。

MCIが構想していたmarketplaceMCIは、オンラインの買い物環境だった。MCIブランドのブラウザー、Webサーバー、注文を受けて履行する加盟店サーバー、技術支援や加盟店アカウントのためのバックエンドが組み合わさる。必要だったのは、注文、請求、配送の情報を複数のリクエストにわたってつなぐことだった。

設計の選択は、孤独な発明家の逸話ではなく、後年の裁判記録に現れる。1994年8月10日の会合で、MCIはNetscapeが最初に示したサーバー側への状態保存案を拒み、クライアント側のコンピューターへの保存を求めた。裁判所はこの一般的な要件への合意を争いのないものとして記しつつ、一部の技術的詳細には異論があったことも残している。

この要件によって、アプリケーションの短期的な記憶の置き場所が変わった。サーバーとのやり取りの間、ブラウザーが小さな状態オブジェクトを保持する。Netscapeのプログラマー、Lou Montulliが課題を担当した。Montulliは後に、HTTPのセッションレスな性質を補う買い物かご方式を夏に求められたと回想したが、具体的な顧客がMCIだったとは覚えていなかった。Marc Andreessenは、MCI案件が最終的にCookieにつながり、Netscapeが汎用機能へ広げたと証言している。顧客要件と製品判断のつながりは見えるが、設計史の細部すべてが確定したわけではない。

ブラウザーがアプリケーション状態を運び始めた

保存されたNetscape仕様は、仕組みを簡潔に説明する。サーバーはHTTPレスポンスに状態オブジェクトを添えられる。ブラウザーが保存し、Cookieの適用範囲に合うURLへの後続リクエストに含めて返す。値を選び、意味を決めるのはサーバーアプリケーションであり、ブラウザーはそれを保持して返す役を担った。

これで買い物かごの参照値、登録情報、利用者の設定を複数のリクエストにまたがって持ち運べる。HTTPが常時接続のプロトコルになったわけではない。利用者ごとの買い物かごを各ページに埋め込む必要もなく、キャッシュにとって都合がよかった。サーバーが仕事をしなくなったわけでもない。返された値をキーとして、別の場所に保管した情報を探す設計も可能だった。

このNetscape文書は「予備仕様」と名乗り、注意して使うよう求めていた。初期の規則はホストまたはドメイン、パス、有効期限、安全な送信などを定め、ブラウザーが状態をいつ返すかを区切った。人の名前、同意、継続的な在席を証明する規則ではなかった。

裁判記録によると、Netscapeのソースコードリポジトリには1994年10月3日または4日までにCookieの草稿コードが入り、10月6日と13日にも変更があった。発明をいつ実際に完成させたかについて、訴訟当事者は正確な日付を争っていた。したがって慎重な年表は、夏の顧客要件と設計、裁判所の記述に基づく10月初旬のコード、その後の汎用機能化となる。全員が認める単一の「発明日」はない。

標準化はブラウザーの提案の後に来た

1997年2月、David KristolとMontulliはRFC 2109「HTTP State Management Mechanism」を公開した。Set-CookieレスポンスとCookieリクエストを説明し、その文法を標準トラックに載せようとした。文書はNetscapeの当初案との互換性も、歴史的経緯として明記していた。標準化とは、すでに流通していたコードや振る舞いを調整する作業でもあった。

RFC 2109は仕組みの境界を率直に示している。ユーザーエージェントはCookieを送るか保存するか、利用者が制御できるようにすべきだった。ヘッダーは通信中に保護されず、機密値は漏れたり改変されたりし得る。Cookieの値はブラウザーには不透明だが、読める場合もある。RFCのログイン例では、まず利用者がフォームで本人を名乗り、その後サーバーが本人性を反映したCookieを返す。Cookieが続けるのは本人確認の後のアプリケーション状態であり、Cookie自体が独立した本人確認になるわけではない。

この区別は大切だ。ブラウザーに保存された値がサービスに役立っても、誰がそれを持っているかは証明されない。アプリケーションが値の所持を権限として扱えば、持参人型のセッション能力ができる。その値を得た者が、適用範囲と有効期間内で再利用できることもある。安全性は発行、保護、失効、取り消しの設計に左右され、基本的なCookieの往復だけでは決まらない。

Cookieの歴史は、その名前が思わせるほど不思議なものではない。買い物の流れを作るため、製品チームは継続性をどこに置くか選ばなければならなかった。ブラウザーがサーバーの選んだ状態を運び、顧客向けの要件が再利用可能な機能となり、後の標準化が実装済みの振る舞いとの互換性を記録した。こうしてWebアプリケーションは、別々のリクエストの間に取引を記憶できるようになった。ブラウザーがその背後の人間の身元を証言するようになったわけではない。

出典と証拠の限界