ハイパーテキスト転送プロトコル (HTTP) とクッキー (調査と解説)

HTTP (HyperText Transfer Protocol) は IETF において標準化された WWW (World Wide Web) におけるデータ転送のためのプロトコルである． HTTP は基本的にサーバが状態保持しない (stateless) プロトコルだが，データベースなどを使用する Web アプリケーションにおいては状態保持が必要だったため，そのためにいわゆる cookie とよばれる機構が Netscape 社によって導入された． Cookie を使用することによって状態を管理し，“セッション” を維持することが可能になる．

1996 年 2 月に HTTP/1.0 (Version 1.0) が RFC 1945 (T. Berners-Lee, R. Fielding, H. Frystyk 著: Hypertext Transfer Protocol -- HTTP/1.0) として発行されたが，これは標準ドキュメントではない． 1997 年 1 月に HTTP/1.1 (Version 1.1) が標準化され，提案標準 (Proposed Standard) RFC 2068 として発行された．その後 HTTP/1.1 は RFC 2616 (R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee 著: Hypertext Transfer Protocol -- HTTP/1.1) によってドラフト標準 (Draft Standard) として発行されている．

ここでは RFC 2616 を中心として HTTP/1.1 に関する調査結果を記述するとともに，cookie を使用したセッション管理の方法について記述する．

1. HTTP の概要

HTTP (HyperText Transfer Protocol) は HTML (HyperText Mark-up Language) や XML (eXtended Mark-up Language) によって記述されたハイパーテキストを転送することをおもな目的としているが，転送する内容はハイパーテキストにかぎられず，バイナリ・データもふくめて，様々なデータをおくることができる． HTTP は要求-応答型のプロトコルである．すなわち，クライアントがサーバに要求メッセージを送信し，サーバがこれに応答メッセージをかえす．応答メッセージをかえした時点で基本的にサーバは初期状態にもどる．すなわち，サーバは状態を保存しない．HTTP においてはトランスポート・プロトコルとして通常 TCP を使用するが，TCP の接続もサーバの応答が終了した時点で切断する．

クライアントは HTTP によって WWW 上の資源など，たとえば Web ページにアクセスするが，この資源を指定するために使用されるのが URI (Uniform Resource Identifier) である． HTTP を使用して資源にアクセスするときは，http: が先頭についた URI を使用する．URI の例をあげる．

http://www.eurecom.fr/~ross/CacheTutorial/tsld050.htm

2. メッセージの構造

メッセージには，クライアントがサーバに対して送信するための要求メッセージと，それにサーバがクライアントに対して応答するための応答メッセージとがある．どちらのメッセージも，開始行があり，それにヘッダがつづき，空行をはさんでメッセージ本体がつづくという構造をしている．

つぎに，要求メッセージの例を示す (http://www.eurecom.fr/~ross/CacheTutorial/tsld050.htm から引用)．

GET /somedir/page.html HTTP/1.0 
User-agent: Mozilla/4.0 
Accept: text/html, image/gif, image/jpeg

ここではメッセージ本体は空である．

また，応答メッセージの例を示す (http://www.eurecom.fr/~ross/CacheTutorial/tsld052.htm から引用)．

HTTP/1.1 200 OK 
Date: Thu, 06 Aug 1998 12:00:15 GMT 
Server: Apache/1.3.0 (Unix) 
Last-Modified: Mon, 22 Jun 1998 09:23:24 GMT
Content-Length: 6821
Connection: close
Content-Type: text/html

data data data ...

3. 要求メッセージの種類

おもな要求メッセージのメソッドはつぎのとおりである．

(1) GET

引数として URI を指定し，その URI にある Web ページなどの内容を要求する．それが正当な要求であれば，サーバは GET メソッドに対する応答においてその内容をかえす． GET メッセージの 2 個の例を前記の RFC 2616 から引用する．

GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org

(2) HEAD

GET メソッドにちかいが，HEAD メソッドによる要求に対してサーバは GET メソッドに対する応答におけるのとひとしいヘッダだけをかえす．

(3) OPTIONS

指定した URI に関する利用可能な通信オプションを問い合わせるためのメソッドである．

OPTIONS * HTTP/1.1

(4) POST

クライアントからサーバに対してフォーム・データなどのエンティティを送信するためのメソッドである．フォーム以外にニュースグループ，メーリングリストなどへの投稿データやデータベースに追加するべきレコードなどを含むことができる．引数として URI を指定するが，この URI にあるエンティティは送信されたデータを処理する (たとえば処理のためのスクリプトをふくむ)．

(5) PUT

指定した URI に格納するべきエンティティを送信するためのメソッドである．編集した Web ページを格納する際などに使用する．

(6) DELETE

指定した URI の資源を削除するためのメソッドである．

4. 応答メッセージの種類

(1) 情報的 (1xx)

100 番台のメッセージは，要求をうけとり，処理中であることをあらわす情報的 (informational) メッセージである．情報的メッセージとしてはつぎのものが定義されている: “100 Continue” (継続中), “101 Switching Protocols”．

(2) 成功 (2xx)

200 番台のメッセージは，要求が受理されたことをあらわす成功メッセージである．成功メッセージとしてはつぎのものが定義されている: “200 OK” (成功した), “201 Created” ((資源が) 生成された), “202 Accepted” (受理された), “203 Non-Authoritative Information”, “204 No Content” (内容が空である), “205 Reset Content”, “206 Partial Content”．

(3) リダイレクション (3xx)

300 番台のメッセージは，要求を実行するためにはクライアントが動作する必要があることをあらわすリダイレクション・メッセージである．リダイレクション・メッセージとしてはつぎのものが定義されている: “300 Multiple Choices” (複数のリダイレクト候補あり), “301 Moved Permanently” (恒久的に場所を移動), “302 Found” (発見された), “303 See Other”, “304 Not Modified”, “305 Use Proxy” (SIP プロキシ使用要求), “307 Temporary Redirect” (一時的なリダイレクト)．

(4) クライアント・エラー (4xx)

400 番台のメッセージは，要求にエラーがあって失敗したことをあらわすクライアント・エラー・メッセージである．クライアント・エラー・メッセージとしてはつぎのものが定義されている: “400 Bad Request” (不正な要求), “401 Unauthorized” (権限不足), “402 Payment Required” (要支払), “403 Forbidden” (禁止), “404 Not Found” (発見できず), “405 Method Not Allowed” (メソッド使用禁止), “406 Not Acceptable” (受理不能), “407 Proxy Authentication Required” (プロキシ認証が必要), “408 Request Time-out” (要求がタイムアウト), “409 Conflict”, “410 Gone” (要求資源は利用不能になった), “411 Length Required”, “412 Precondition Failed”, “413 Request Entity Too Large” (要求エンティティはサーバ能力をこえる), “414 Request-URI Too Large” (要求 URI は過長), “415 Unsupported Media Type” (メディアタイプ利用不能), “416 Requested range not satisfiable”, “417 Expectation Failed”．

(5) サーバ・エラー (5xx)

500 番台のメッセージはサーバにおいてエラーが発生したことをあらわすサーバ・エラー・メッセージである．サーバ・エラー・メッセージとしてはつぎのものが定義されている: “500 Internal Server Error”, “501 Not Implemented”, “502 Bad Gateway”, “503 Service Unavailable”, “504 Gateway Time-out”, “505 HTTP Version not supported”．

5. セッション管理のための拡張

HTTP は基本的にサーバが状態保持しない (stateless) プロトコルである．しかし，WWW が電子商取引などに使用されるようになったため，データベースなどを使用する必要が生じた．たとえば，電子商取引においては買い物かごを使用するのが普通だが，この場合には最低限でも買い物かごの内容を保持する必要がある．このような状態保持が必要なアプリケーションのために，いわゆる cookie という機構が Netscape 社によって導入された (“Persistent Client State -- HTTP Cookies”, http://wp.netscape.com/newsref/std/cookie_spec.html)． Cookie を使用することによって “セッション” を維持することが可能になる．

Netscape 社が導入したプロトコル拡張はつぎのようなものである．状態保持する必要がある Web ページをクライアントが要求すると，サーバは Set-Cookie ヘッダをふくむ応答メッセージをかえす． Set-Cookie ヘッダには状態情報を識別するための名前とその値とからなる対がふくまれる．また，この状態情報の有効期限や他の補足情報がふくまれる．補足情報のなかには Secure という，クライアント-サーバ間の接続にセキュアな手段を使用することを要求するものもあるが，これについては ??? 節において述べる．

Set-Cookie ヘッダの例をあげる (http://wp.netscape.com/newsref/std/cookie_spec.html)．

Set-Cookie: CUSTOMER=WILE_E_COYOTE; path=/; expires=Wednesday, 09-Nov-99 23:12:40 GMT

ここでは状態情報の名前が CUSTOMER, その値が WILE_E_COYOTE である．これは，このセッションが WILE_E_COYOTEという顧客のセッションであることをあらわしている．ただし，通常は値として，不正な書き換えが困難な，より複雑な文字列を使用する．

Cookie ヘッダをふくむ応答を受信したクライアントは，それを拒絶し，このヘッダがふくまれていなかったかのように応答することもできる．しかし，それを受諾する場合は，つぎにサーバに要求を送信する際に，サーバが送付してきた状態情報の名前と値とをふくむ Cookie ヘッダを付加する:

Cookie: CUSTOMER=WILE_E_COYOTE

この Cookie ヘッダの返信をもって，セッションが確立される．

2000 年 10 月に発行された RFC 2965 (D. Kristol, L. Montulli 著: HTTP State Management Mechanism) においては Netscape 社の状態保持機構を改良したプロトコル拡張が標準化されている (正確には，Netscape 社の状態保持機構の改良版として，まず 1997 年 2 月に発行された RFC 2109 が標準化され，その改訂版としてRFC 2965 が標準化された)．前記の RFC 2965 に記述された機構は Netscape 社の状態保持機構とは互換でないため，Set-Cookie ヘッダのかわりに Set-Cookie2 ヘッダを使用する．状態情報の名前と値の対を指定する点では変わらないが，有効期限や補足的な情報の指定法が Netscape 社のプロトコル拡張とはことなっている． Set-Cookie2 ヘッダの例をあげる．

Set-Cookie2: Customer="WILE_E_COYOTE"; Version="1"; Path="/acme"

これに対する要求メッセージに含まれる Cookie ヘッダはたとえばつぎのとおりである．

Cookie: $Version="1"; Customer="WILE_E_COYOTE"; $Path="/acme"

2000 年 10 月に発行された RFC 2964 (K. Moore, N. Freed 著: Use of HTTP State Management) には，前記の RFC 2965 に記述された HTTP 状態管理の使用法について記述されている．勧められる用法と問題がある用法の両方が示されている．これらはみなセキュリティに関する記述なので，内容については ??? 節において述べる．

6. 標準的なシーケンス

状態管理をおこなわない場合は対をなす要求と応答とだけでシーケンスがとじるので，その例は示さない．ここでは，HTTP 状態管理機構を使用したセッションのシーケンス例を前記の RFC 2965 から引用する (一部の空行を削除し複数のフォントを使用しているが，それ以外は原文のままである)．

1. User Agent → Server
  POST /acme/login HTTP/1.1
  [form data]

  User identifies self via a form.

2. Server → User Agent
  HTTP/1.1 200 OK
  Set-Cookie2: Customer="WILE_E_COYOTE"; Version="1"; Path="/acme"

  Cookie reflects user’s identity.

3. User Agent → Server
  POST /acme/pickitem HTTP/1.1
  Cookie: $Version="1"; Customer="WILE_E_COYOTE"; $Path="/acme"
  [form data]

  User selects an item for “shopping basket”.

4. Server → User Agent
  HTTP/1.1 200 OK
  Set-Cookie2: Part_Number="Rocket_Launcher_0001"; Version="1";
          Path="/acme"

  Shopping basket contains an item.

5. User Agent → Server
  POST /acme/shipping HTTP/1.1
  Cookie: $Version="1";
          Customer="WILE_E_COYOTE"; $Path="/acme";
          Part_Number="Rocket_Launcher_0001"; $Path="/acme"
  [form data]

  User selects shipping method from form.

6. Server → User Agent
  HTTP/1.1 200 OK
  Set-Cookie2: Shipping="FedEx"; Version="1"; Path="/acme"

  New cookie reflects shipping method.

7. User Agent → Server
  POST /acme/process HTTP/1.1
  Cookie: $Version="1";
          Customer="WILE_E_COYOTE"; $Path="/acme";
          Part_Number="Rocket_Launcher_0001"; $Path="/acme";
          Shipping="FedEx"; $Path="/acme"
  [form data]

  User chooses to process order.

8. Server → User Agent
  HTTP/1.1 200 OK

  Transaction is complete.

Keywords:

調査と解説