TITLE : クライアント側の状態 日本語参考訳 - HTTP Cookies 永続的な クライアントの 状態 HTTP COOKIES 仕様（草稿） - 注意の上利用してください この文書は参考訳です(原文/ENGLISH) -------------------------------------------------------------------------------- 導入 Cookies はサーバーから送られた情報（CGIスクリプト等）を、クライアント側 で保存し 、かつ回復させる一般的な機構です。この簡単で持続性のある クライアントの状態情報 のための追加仕様は Web ベースのクライアント／サーバー アプリケーションの可能性を 広げる意義深いものです。 概観 サーバーが、クライアントに HTTP オブジェクトを返すとき、クライアントに 保存する ためのいくつかの State を一緒に返します。その State オブジェクト には、State が 有効であるURLの範囲も含まれます。その範囲に一致するURLに クライアントがアクセス するときは必ず、現在保存されている State の値を HTTP リクエストに含めてサーバー に発行します。この State オブジェクトの ことをここでは cookie と呼ぶことにします 。 この簡単な機構はWeb環境において様々な便利で新しいタイプのアプリケーション の作成 を可能にします。インターネットショッピングのページでは、現在、 選択されているア イテムの情報を保存することが出来ますし、有料サービスの ページではいちいちユーザ ーIDをお客様に打ち込んでもらう必要はありません。 サイトはユーザー一人ずつのデー タをクライアントに保存できます。そして、 サイトにアクセスがあればその情報はクラ イアントによって自動的に提供されるのです。 仕様 クッキーは HTTP レスポンスの際に Set-Cookieheader を含めることで クライアントに 導入されます。典型的には、CGIスクリプトによって生成されます。 Set-Cookie HTTP レスポンスヘッダの文法 以下、CGIスクリプトが HTTP レスポンスヘッダに追加するための書式です。 これらの情 報はクライアントによって、保存され、回復されることになります。 Set-Cookie: NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME; secure NAME=VALUE この文字列はセミコロン、コンマとスペースを除いた文字によって構成される。 それ らの文字を NAME (以下、名前) または VALUE に必要とする場合には、 予め変換されて いる必要があります。%XXといった形で変換する URL エンコード を推奨します。なお、 それらの文字は、予約または定義されています。 この属性のみ Set-Cookie ヘッダでは必須です expires=DATE expires 属性は cookie の有効期日を指定します。期限切れになると、 cookie は自 動的に送出されなくなるか、削除されます。 日付の形式は次のようなものです: Wdy, DD-Mon-YYYY HH:MM:SS GMT これは以下のRFC RFC 822, RFC 850, RFC 1036, と RFC 1123,とこれらのバリエーション に基づいています。タイムゾーン については GMT のみで、日付はダッシュ(-)で結びま す。 expires は追加属性です。この指定がなければ、セッションが終了した 段階で cookie は無効になります。 Note: Netscape Navigator version 1.1 より以前のバージョンにはバグがあります。 こ れらのブラウザでは、"/" に関連付けられたされたcookieで、 expires 属性が指定され ていたもののみセッション間で保存されます。 domain=DOMAIN_NAME 有効な cookie を探す場合は、ドメイン名で構成された domain 属性の比較で行われ ます。後方検索で一致すると、次の path 検索を 行って送るべきか否かを決定します。" 後方一致検索" とは domain 属性をドメイン名の末尾から一致させていくことです。 "ac me.com"　という domain 属性は "anvil.acme.com" や "shipping.crate.acme.com" に一 致します。 特定のドメインに属するホストのみが少なくとも2個または3個のピリオドを含む形式のド メインや複数ドメインの cookie を設定できます。: ".com", ".edu", と "va.us"。 後 にあげる7つの特別なトップドメインは二つのピリオドを必要とします。他のドメインで は少なくとも3つ必要になります。7つのトップドメインは次のようなものです: "COM", " EDU", "NET", "ORG", "GOV", "MIL", と "INT"。 domain の既定値は cookie レスポンスによって生成されたサーバーの ホスト名です。 path=PATH path 属性はドメインの中のどこの URL でその cookie が有効なのか を指定するため に使います。cookie が domain で一致したら、次に path 属性で比較され、両方が一致 したときにその cookie は有功だとみなされ、 リクエストとともに送信されます。path "/foo" は "/foobar" と "/foo/bar.html" にも一致します。 path "/" は最も一般的な path です。 path が指定されなかった場合は、cookie ヘッダを含む文書と同じ場所 であるものとみ なされます。 secure cookie に secure 属性がついているときは、ホストとの通信が保護されている 場合 にのみ送信されます。現在のところ、この属性のついた cookie は HTTPS (HTTP over SS L) サーバーにのみ送信されます。 もし secure 属性が指定されなければ、cookie は安全なものだとみなして そのまま保護 せずに送信されます。 Cookie HTTPリクエストヘッダの書式 HTTP サーバーにアクセスするとき、ブラウザは URL に一致する全ての Cookieを まとめ て HTTP リクエストに含めます。書式は次のようになります: Cookie: NAME1=OPAQUE_STRING1; NAME2=OPAQUE_STRING2 ... 補遺 * 一度に複数の Set-Cookie ヘッダを返すことが出来ます。 * 同じ path 同名の cookie は、最後に更新されたもので上書きされます。 同じ pa th であっても名前が違えば違うものとして扱われます。 * より上位の path に値を設定するときに、下位の特定の path に関連付けられた c ookie を上書きしてしまうことはありません。もし複数の同名で違う path の cookie が一致した場合は、一致したもの全てが送られます。（下の使用例をご覧ください。） * expire ヘッダはクライアントにいつになったら安全に関連付けを破棄できるか 知 らせるものですが、必ずしもこれを守る必要はありません。クライアントは 内部の限 界などに応じて、有効期限がくる前に破棄してしまうことができます。 * cookie をサーバーに送るときは、path がより一致するものを先に送る ようにす るべきです。例えば、"/" に関連付けられた "name1=foo" と "/bar" に関連付けられ た "name1=foo2" を同時に送信する場合、 後者を先に送信すべきです。 * クライアントが一度に保存できるcookiesには制限があります。 クライアントは以 下の数のクッキーを最低限、受け入れ、保存でき るようにするべきです。 * 全部で300個まで。 * クッキー1つにつき name と OPAQUE_STRING をあわせて 4 KBまで。 * 1つのサーバーまたはドメインにつき20個まで。 (ただし、完全なホスト名とドメ イン属性である場合は別のものとして扱われ、合計されません) サーバーはクライアントにこの制限以上のことを想定すべきではありません。 300個以 上になったり、一つのサーバーあたり20個を超えたりした場合、 クライアントはもっ とも最近使ったcookieを削除します。また、4 KB を 超えた場合には制限に合うように 切り捨てられます。ただし、名前に関しては 4KBを超えない限りそのまま残ります。 * CGI スクリプトからcookieを削除したいときは、同名のcookieと expiresを昔の日 付、つまり期限切れにして送ります。 path と名前が一致すれば有効な cookie が期限 切れの cookie に 置き換わります。これは cookie の作成者以外の cookie の削除を 防止するためのものです。 * HTTP をプロキシーサーバーなどでキャッシングしている場合でも、 Set-cookieレ スポンスヘッダはキャッシュしてはいけません。 * プロキシーサーバーがSet-cookieヘッダを含むレスポンス を受け取った時は、レ スポンスが304(Not Modified) であれ、200 (OK)であれ いずれにしろSet-cookieをク ライアントに返すべきです。 同様に、クライアントからのリクエストに Cookie: ヘッダが含まれていた ときは、If -modified-since リクエストであったとしてもプロキシーを透過させるべきです。 使用例 ここにいくつか cookies の使い方を説明するために作成されたサンプルです。 第一の送受信手順の例: クライアントが文書を呼び出して、そのレスポンスの中に次のようなヘッダがあった: Set-Cookie: CUSTOMER=WILE_E_COYOTE; path=/; expires=Wednesday, 09-Nov-99 23:12:4 0 GMT クライアントがこのサーバーの "/" にアクセスすると次のように送信される: Cookie: CUSTOMER=WILE_E_COYOTE クライアントが文書を呼び出して、そのレスポンスの中に次のようなヘッダがあった: Set-Cookie: PART_NUMBER=ROCKET_LAUNCHER_0001; path=/ クライアントが再びこのサーバーの "/" にアクセスすると次のように送信される: Cookie: CUSTOMER=WILE_E_COYOTE; PART_NUMBER=ROCKET_LAUNCHER_0001 クライアントが次のヘッダを受け取る: Set-Cookie: SHIPPING=FEDEX; path=/foo クライアントが三度このサーバーの "/" にアクセスすると次のように送信される: Cookie: CUSTOMER=WILE_E_COYOTE; PART_NUMBER=ROCKET_LAUNCHER_0001 また、クライアントがこのサーバーの "/foo" にアクセスすると次のように送信される: Cookie: CUSTOMER=WILE_E_COYOTE; PART_NUMBER=ROCKET_LAUNCHER_0001; SHIPPING=FEDEX 第二の送受信手順の例: 第一の例はなかったものとする。 まずクライアントが次のヘッダを受け取る: Set-Cookie: PART_NUMBER=ROCKET_LAUNCHER_0001; path=/ クライアントがこのサーバーの "/" にアクセスすると次のように送信される: Cookie: PART_NUMBER=ROCKET_LAUNCHER_0001 再びクライアントが次のヘッダを受け取る: Set-Cookie: PART_NUMBER=RIDING_ROCKET_0023; path=/ammo クライアントがこのサーバーの "/ammo" にアクセスすると次のように送信される: Cookie: PART_NUMBER=RIDING_ROCKET_0023; PART_NUMBER=ROCKET_LAUNCHER_0001 NOTE: "/" と "/ammo" の両方の設定を継承するため "PART_NUMBER" が二度出てくるこ とになります。 -------------------------------------------------------------------------------- 法人向け販売: 650/937-2555 ・ 法人向けアップグレード販売: 650/937-2929 ・ 個 人向け販売: 650/937-3777 ・ 官公庁向け販売: 650/937-3678 ・ 学校向け販売: 650/93 7-2810 もし何か疑問があればカスタマーサービスのサイトにアクセスするか、お近くの 営業所 に連絡してください。 Copyright (C) 1998 Netscape Communications Corporation. 日本語訳 Copyright? (C) 1998 OCU Fac of bus & KOU-GEN-SHA Soft Lab,.