読者です 読者をやめる 読者になる 読者になる

脳汁portal

アメリカ在住(だった)新米エンジニアがその日学んだIT知識を書き綴るブログ

cookieとは

同じくPCを整理していたら(ry

cookieとは

  • HTTPにおいて、クッキー{Cookie}とは、元々ユーザエージェント(Webブラウザ)によって保存される「小さな」ファイルを指す
  • クッキーは、専用のHTTPヘッダ、あるいはJavaScriptにより利用することができる
  • HTTPでは“状態{State}”を保持することはできない
    • ここでいう“状態”とは、「過去からのHTTPリクエスト-レスポンス結果を踏まえた“状態”」という意味なので、すなわち「“状態”を保持する」とは「前回のHTTPリクエスト結果を踏まえた上で、今回のHTTPリクエストを送信する」ということ
    • HTTPでは、ハイパーテキストの大量な要求に素早く対応できるようにするために、「あえて“状態”を持たないように」設計した
  • WWWが爆発的に普及し、様々な場面でWebが(=HTTPが)利用されるようになるにつれて、“状態”を保持したいというHTTPの性質に反するニーズが出てきた
  • 「WebブラウザがあらかじめWebサーバから受け取った“状態”の情報をファイルに保存しておき、次回 Webサーバと交信{Session}する時にWebブラウザがそれをWebサーバに送り返す」というアイデアを考えつき実装

⇒これがクッキーの始まり

Cookie の使い方

  • Netscape社が開発したクッキーという技術は、Set-CookieCookieという2種類のHTTPヘッダのやりとりで状態を管理しようとするもの

Set-Cookie

  • クッキーは、まずサーバがSet-Cookieというヘッダを発行する所から始まります。
サーバがクライアントにクッキーを送るときのレスポンスヘッダの例
HTTP/1.1 200 OK
Date: Sun, 03 Jun 2001 12:00:00 GMT
Server: Apache/1.3.14
Set-Cookie: num=123456; expires=Sun, 10-Jun-2001 12:00:00 GMT; path=/HTTP/
Last-Modified: Fri, 01 Jun 2001 00:00:00 GMT
Content-Length: 999
Content-Type: text/html
Netscape社のクッキーにおける、Set-Cookieヘッダのフォーマット
Set-Cookie: NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME; secure
  • NAME=VALUE
    • クッキーの名前とその値を指定します。 Set-Cookieでは、唯一の必須属性
  • expires=DATE
    • クッキーの有効期限
    • expires 属性が省略されたクッキーは、クライアントとサーバの接続が終了した時に削除される
    • また、Dateが過去の日付を持っているクッキーは、そのクッキーを受け取った時点で破棄される
  • path=PATH
    • クッキーを送り返すURLのサブセットを指定
    • リクエストを送るURLにpath条件が一致した場合に、クッキーは有効とみなされ、リクエストと一緒に送られます
    • path属性は、前から順に一致しているかどうかをチェックします(前方一致)
      • /fooというpathは、/foobarや/foo/bar.htmlに一致
      • /というpathは、そのサーバ内の全てのリソースに一致
    • 省略されたクッキーは、そのクッキーを含んでいるヘッダによって記述されているドキュメントと同じpathが指定されたとみなす
  • domain=DOMAIN_NAME
    • クッキーを送り返すサーバのドメイン名を指定します。
    • リクエストを送るURLにdomain条件が一致した場合に、クッキーは有効とみなされ、リクエストと一緒に送られます

Cookie

  • Set-Cookieヘッダを受け取ったクライアントは、送り返す条件に一致したクッキーについては、リクエストメッセージと共にCookieというヘッダを発行する
Cookieヘッダのフォーマット
Cookie: NAME1=OPAQUE_STRING1; NAME2=OPAQUE_STRING2; ...
    • このように、条件に合ったクッキーが“名前=非空白文字列”の形式で与えられる
    • クッキーが複数ある場合は“;”で区切られる

実際の使用例

1. ユーザエージェント -> サーバ (ユーザはフォームを通して個人を識別するために個人情報を入力します。)

POST /shopping/login HTTP/1.1
[form data]

2. サーバ -> ユーザエージェント(クッキーがユーザの個人情報を反映します。)

HTTP/1.1 200 OK
Set-Cookie: Customer="nouziru"; Path="/shopping";

3. ユーザエージェント -> サーバ (以降、クライアントがこのサーバ上の path "/shopping" 以下の URL にリクエストをする時には、上のクッキーをサーバに送ります。)

POST /shopping/pickitem HTTP/1.1
Cookie: Customer="nouziru";
[form data]

4. サーバ -> ユーザエージェント(クライアントが /shopping/pickitem で品目を選んだとして、サーバはその品目を含めます。)

HTTP/1.1 200 OK
Set-Cookie: Part_Number="IBMPC_01"; Path="/shopping"

5. ユーザエージェント -> サーバ (以降、クライアントがこのサーバ上の path "/shopping" 以下の URL にリクエストをする時には、上のクッキーをサーバに送ります)

POST /shopping/shipping HTTP/1.1
Cookie: Customer="nouziru"; Part_Number="IBMPC_01";
[form data]

6. サーバ -> ユーザエージェント(クライアントが /shopping/shipping で発送方法を選んだとして、サーバはその発送方法を反映します。)

HTTP/1.1 200 OK
Set-Cookie: Shipping="Dokoka"; Path="/shopping"

7. ユーザエージェント -> サーバ(以降、クライアントがこのサーバ上の path "/shopping" 以下の URL にリクエストをする時には、上のクッキーをサーバに送ります。)

POST /shopping/process HTTP/1.1
Cookie: Customer="nouziru"; Part_Number="IBMPC_01"; Shipping="Dokoka";
[form data]

8. サーバ -> ユーザエージェント (通信処理は完了します。)

HTTP/1.1 200 OK
  • ユーザエージェントは、新しいクッキーを受け取る度に、オリジンサーバ上に一続きのリクエストを作っている
  • すべてのクッキーは、同じ Path 属性と、ここでは指定されていない既定ドメインを持っている
  • Request-URI はすべて、それぞれのクッキーの Path 属性である /shopping とパス一致しているので、それぞれのリクエストはそこまでに受信したすべてのクッキーを含んでいる