1. はじめに (Introduction)

本文書は、HTTP Cookie (クッキー) と Set-Cookie ヘッダーフィールドを定義します。Set-Cookie ヘッダーフィールドを使用して、HTTPサーバーは名前/値のペアと関連するメタデータ (クッキーと呼ばれる) をユーザーエージェント (User Agent) に渡すことができます。ユーザーエージェントがサーバーに後続のリクエストを行うとき、ユーザーエージェントはメタデータとその他の情報を使用して、Cookie ヘッダーで名前/値のペアを返すかどうかを決定します。

表面的には単純ですが、クッキーには多くの複雑さがあります。例えば、サーバーはユーザーエージェントにクッキーを送信する際、各クッキーのスコープ (Scope) を示します。スコープは、ユーザーエージェントがクッキーを返すべき最大時間、クッキーを返すべきサーバー、およびクッキーが適用可能な URI スキーム (URI Scheme) を示します。

歴史的な理由により、クッキーにはセキュリティとプライバシーを損なう多くの問題が含まれています。例えば、サーバーは特定のクッキーが「セキュア (Secure)」な接続を対象としていることを示すことができますが、Secure 属性 (Secure Attribute) はアクティブなネットワーク攻撃者の存在下では整合性 (Integrity) を提供しません。同様に、特定のホストのクッキーはそのホストのすべてのポート間で共有されますが、Webブラウザが使用する通常の「同一オリジンポリシー (Same-Origin Policy)」は、異なるポート経由で取得されたコンテンツを分離します。

本仕様には2つの対象者がいます: クッキー生成サーバーの開発者とクッキー消費ユーザーエージェントの開発者です。

ユーザーエージェントとの相互運用性を最大化するために、サーバーはクッキーを生成する際、セクション4で定義された適切な動作プロファイルに自身を制限すべきである (SHOULD)。

ユーザーエージェントは、セクション4で定義された適切な動作プロファイルに準拠しない既存のサーバーとの相互運用性を最大化するために、セクション5で定義されたより寛容な処理ルールを実装しなければならない (MUST)。

本文書は、これらのヘッダーがインターネット上で実際に使用されている構文とセマンティクスを規定します。特に、本文書は現在使用されているものを超えた新しい構文やセマンティクスを作成しません。セクション4で提供されるクッキー生成の推奨事項は、現在のサーバー動作の推奨サブセットを表しており、セクション5で提供されるより寛容なクッキー処理アルゴリズムでさえ、現在使用されているすべての構文および意味的なバリエーションを推奨するわけではありません。既存のソフトウェアが推奨プロトコルと大きく異なる場合、本文書にはその違いを説明する注記が含まれています。

本文書より前には、クッキーに関する少なくとも3つの記述がありました: いわゆる「Netscape クッキー仕様 (Netscape Cookie Specification)」[Netscape]、RFC 2109 [RFC2109]、および RFC 2965 [RFC2965]。しかし、これらの文書のいずれも、Cookie および Set-Cookie ヘッダーがインターネット上で実際にどのように使用されているかを記述していません (歴史的背景については [Kri2001] を参照)。HTTP状態管理メカニズムの以前のIETF仕様との関連で、本文書は次のアクションを要求します:

[RFC2109] のステータスを歴史的 (Historic) に変更する (すでに [RFC2965] によって廃止されています)。
[RFC2965] のステータスを歴史的に変更する。
[RFC2965] が本文書によって廃止されたことを示す。

特に、RFC 2965 を歴史的なものに移行し廃止することで、本文書は Cookie2 および Set-Cookie2 ヘッダーフィールドの使用を非推奨とします。