[技術文書] 永続的な クライアントの 状態 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 属性をドメイン名の末尾から一致 させていくことです。 "acme.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 SSL) サーバーにのみ送信されます。 もし secure 属性が指定されなければ、cookie は安全なものだとみなして そ のまま保護せずに送信されます。 Cookie HTTPリクエストヘッダの書式 HTTP サーバーにアクセスするとき、ブラウザは URL に一致する全ての Cookieを ま とめて HTTP リクエストに含めます。書式は次のようになります: Cookie: NAME1=OPAQUE_STRING1; NAME2=OPAQUE_STRING2 ... 補遺 * 一度に複数の Set-Cookie ヘッダを返すことが出来ます。 * 同じ path 同名の cookie は、最後に更新されたもので上書きされます。 同じ path であっても名前が違えば違うものとして扱われます。 * より上位の path に値を設定するときに、下位の特定の path に関連付けられ た cookie を上書きしてしまうことはありません。もし複数の同名で違う path の cookie が一致した場合は、一致したもの全てが送られます。(下の使用例 をご覧ください。) * expire ヘッダはクライアントにいつになったら安全に関連付けを破棄できるか 知らせるものですが、必ずしもこれを守る必要はありません。クライアントは 内部の限界などに応じて、有効期限がくる前に破棄してしまうことができま す。 * cookie をサーバーに送るときは、path がより一致するものを先に送る ように するべきです。例えば、"/" に関連付けられた "name1=foo" と "/bar" に関連 付けられた "name1=foo2" を同時に送信する場合、 後者を先に送信すべきで す。 * クライアントが一度に保存できるcookiesには制限があります。 クライアント は以下の数のクッキーを最低限、受け入れ、保存でき るようにするべきです。 o 全部で300個まで。 o クッキー1つにつき name と OPAQUE_STRING をあわせて 4 KBまで。 o 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:40 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/937-2810 もし何か疑問があればカスタマーサービスのサイトにアクセスするか、 お近くの 営業所に連絡してください。 Copyright c) 1998 Netscape Communications Corporation. 日本語訳 Copyright? c) 1998 OCU Fac of bus & KOU-GEN-SHA Soft Lab,.