[画像のクリックで拡大表示]
[画像のクリックで拡大表示]
[画像のクリックで拡大表示]
[画像のクリックで拡大表示]
[画像のクリックで拡大表示]
[画像のクリックで拡大表示]
[画像のクリックで拡大表示]
[画像のクリックで拡大表示]
[画像のクリックで拡大表示]
[画像のクリックで拡大表示]
[画像のクリックで拡大表示]
[画像のクリックで拡大表示]
[画像のクリックで拡大表示]
[画像のクリックで拡大表示]
[画像のクリックで拡大表示]
[画像のクリックで拡大表示]
[画像のクリックで拡大表示]
[画像のクリックで拡大表示]

この記事は,日経ソフトウエア2007年2月号,連載「簡単実装で学ぶWeb技術2006」の第8回「Cookie――状態管理とトラッキング」の再録です。記事は執筆時の情報に基づいており,現在では異なる場合があります。

結城 浩(ゆうき ひろし)
1963年生まれ。仕事&趣味は「プログラム書き&文章書き」。JavaやPerlの入門書で人気の著者。Webサイトはhttp://www.hyuki.com/

 こんにちは,結城浩です。

 今回は,Webで状態を管理する際の基本技術である「Cookie(クッキー)」を紹介します。サンプル・プログラムを通してCookieの仕組みを学びましょう。サンプル・プログラムは,Cookieの読み書きを試す簡単なものから,ユーザーのアクセス追跡やログイン状態の管理などの機能を備えた実用的なものまでを紹介します。

 ここで紹介するサンプル・プログラムは,日経ソフトウエアのWebサイトからダウンロードできます。ダウンロード・ページ中で,2007年2月号の「簡単実装で学ぶWeb技術2006 第8回」を参照してください。

●日経ソフトウエア2007年2月号のダウンロード・ページ
http://itpro.nikkeibp.co.jp/article/MAG/20061212/256629/?ST=nsw#200702

Cookieとは

 Cookieを一言で説明すると「Webサーバー(HTTPサーバー)からWebブラウザ(HTTPクライアント)へ渡され,それ以降のアクセスでWebブラウザからWebサーバーに返される情報」です。でも,これではわかりにくいですね。順を追って説明しましょう。

 Webで使われているHTTPはステートレスなプロトコルです。ステートレスとは,サーバーが,クライアントの「状態(ステート)」を管理しない,という意味です。Webサーバーはクライアントからのリクエスト一つひとつを独立したものとして扱います。図1のように,リクエストAとリクエストBが続けてやってきた場合でも,サーバーは,「リクエストBはリクエストAの“続き”だな」と判断できないのです。

図1●HTTPはステートレス
図1●HTTPはステートレス

 ユーザーがWebブラウザを使ってWebページをただ閲覧しているだけなら,HTTPがステートレスでも問題ありません。しかし,Web上でショッピングをしたり,サイトにログインしたりして作業するときには問題になります。

 Web上のショッピング・サイトを利用する場合で考えてみましょう。ショッピングをするときには,「ショッピング・カート」に商品を入れます。あちこちクリックしてもショッピング・カートの中に入れた商品はなくなりません。Webアプリケーションは「いまアクセスしているこのユーザーは,先ほどこの商品を入れたユーザーと同じである」と判断しています。すなわち,Webアプリケーションが,どのクライアントからのアクセスかを識別して,クライアントごとの状態を覚えていることになります。

 ここで紹介するCookie(クッキー)は,複数のリクエストが,同じユーザーからのものかどうかをWebアプリケーション側で判断するための仕組みです。図2にCookieを使って状態を管理している様子を示します。

図2●Cookieを使って状態を管理する仕組み
図2●Cookieを使って状態を管理する仕組み [画像のクリックで拡大表示]

 まず,WebブラウザがWebアプリケーションに対してリクエストAを送ります。Webアプリケーションは,このリクエストAに対して,WebブラウザにレスポンスAを返します。その際に,Cookieと呼ばれる情報をレスポンスAに含めます。具体的には,以下のような1行がHTTPレスポンスのヘッダー部に付加されます。

Set-Cookie: key1=value1

 この例では,key1という名前のCookieの値は「value1」である,ということを表しています。

 Cookieを受け取ったWebブラウザは,今後,同じサーバーにリクエストを送信する際,このCookieを自動的に付加します。図2ではリクエストBに相当します。具体的には,以下のような1行がHTTPリクエストのヘッダー部に付加されます。

Cookie: key1=value1

 リクエストBを受け取ったWebアプリケーションは,ヘッダーを調べ,先ほどレスポンスAで送ったCookieと同じものがやってきたことがわかります。これによって「レスポンスAを受け取ったWebブラウザと,リクエストBを送ってきたWebブラウザは同じ」と判断できるのです。

 これ以降,すべてのリクエストには同じCookieが自動的に付加されます。Webアプリケーション側は,やってくるリクエストに付加されているCookieを調べることで,ある特定のWebブラウザからのアクセスを,ずっと追い続けることができます。一度クライアントにCookieを受け取らせたあとは,WebアプリケーションからのレスポンスにはCookieを付けても付けなくてもかまいません。また,Webアプリケーションが再度Cookieを送り込めば,クライアントのCookieの内容を上書きできます。

 Cookieの有効期限が切れると,WebブラウザはもうサーバーへCookieを送りません。有効期限切れのCookieは削除されます。Webアプリケーション側から,Webブラウザにすでに送り込んだCookieを削除したい場合は,有効期限を過去にしたCookieをセットします。Webアプリケーションは,ブラウザに送り込んだCookieをこのようにして削除します。

 以上が,Cookieを使った状態管理の基本です。

Set-Cookieの形式

 Webアプリケーションが,クライアントにCookieを送り込むときに,HTTPレスポンスのヘッダーに書く「Set-Cookie」の形式は以下のようになります。

Set-Cookie: Cookie名=値; domain=ドメイン名;path=パス名;
 expires=有効期限; secure

 この画面上では複数行で表示されていますが,実際のデータは1行です。詳細はRFC2109*1を参照してください。

 Cookie名と値は必須です。

 ドメイン名とパス名はオプションです。これは,Cookieが有効なドメインおよびパスを表します。ドメイン名として,CookieをセットしようとするWebアプリケーションのあるサーバーのドメインと無関係な文字列は指定できません。ブラウザは,HTTPリクエストのヘッダーにCookieを含めるかどうかを,このドメインとパスで判断します。例えば,「domain=nikkeibp.co.jp; path=/nsw/」と指定したときは,nikkeibp.co.jpの/nsw/にHTTPリクエストを送る場合にだけ,Cookieを付加します。Cookieにドメイン名やパス名が書かれていない場合は,Cookieを得たときのHTTPレスポンスにあるドメインとパスを利用して,得たCookieをサーバーに送るかどうかをブラウザが判断します。

 有効期限もオプションです。これはクライアントがサーバーにCookieを送る限界の日時を表します。有効期限の指定がない場合は,ブラウザの終了までが,Cookieの有効期限になります。

 secureもオプションです。これが書かれていると,ブラウザはSSLなどのセキュアな経路を利用している場合に限ってCookieを送信します。

 実際にプログラムでCookieを作るときには,ライブラリを使うことが多いでしょうから,Set-Cookieの形式をプログラマが意識することは,めったにないでしょう。