プロローグで見てきたように,Webアクセスに使うHTTPにはセッションの概念がなく,そのままでは複数Webページをまたがった一連の通信を「セッション」として認識できない。そこでWebサイトがWebブラウザとの間のセッションを認識し,処理の進行状態を把握する「セッション管理」のしくみが必要になる。ステップ1ではこのしくみを見ていこう。
セッションIDでアクセスをのり付け
セッション管理は,セッションを認識するところから始まる。セッションの認識は,「セッションID」のやりとりで実現する(図1-1)。セッションIDは,セッションを識別するための短いデータである。WebサイトがセッションIDを発行してWebブラウザに預け,一連のアクセスで同じセッションIDを送信してもらう。同じセッションIDが送られてきたことで,同一セッションと認識する。
セッションIDのやりとりを順番に見ていこう。セッションの開始のきっかけは,Webブラウザからのアクセスだ。最初のWebアクセスを受け付けたWebサイトは,Webページを生成するのと並行して,セッションIDを生成する。セッションIDには十数桁以上の乱数が使われることが多い。Webサイトは,セッションIDと共にセッションを管理するデータを書き込むための「セッション・オブジェクト」も作っておく。
Webサイトは,応答のWebページと一緒に生成したセッションIDを送る。これでWebサイト側は,セッションを確立して次のアクセスを待つ状態になる。
セッションIDを受け取ったWebブラウザは,そのサイトへの一連のWebアクセスのときに,Webページの要求と共にセッションIDを送信する。同一セッションであれば同じセッションIDが送られてくるので,Webサイトは確実にセッションを識別できる。さらにWebサイトは,送られてきたセッションIDに対応するセッション・オブジェクトを参照して,そこに書き込まれた情報を基に処理を進める。
よく使われる「Cookie」
では,WebサイトとWebブラウザは,どのような手段でセッションIDをやりとりしているのだろうか。その方法は,おもに3種類ある(図1-2)。
最もポピュラーなのは,Cookieを使う方法だ(図1-2のA)。Cookieは,WebサイトとWebブラウザの間でやりとりする小さなデータ。まずWebサイトがWebブラウザにCookieを送り,次回以降のアクセスで送り返してもらうことができる。Webサイトの多くはこのCookieでセッションを管理する。
Cookieを使うWebサイトは,Webブラウザに送るHTTPレスポンスの拡張ヘッダーに,CookieとしてセッションIDを書き込んで送る。Cookieを受けとったWebブラウザは,そのCookieを持っておく。そして,そのWebサイトへの一連のアクセスのときに,HTTPリクエストの拡張ヘッダーにCookieを付けて送信する。Webサイトは,受け取ったCookieに含まれるセッションIDを見てセッションを識別するわけだ。
Cookieは,Webサイトが指定した有効期限までの間,Webブラウザが保存し続ける。Webブラウザはこの間,いつWebサイトにアクセスしても同じCookieを送ることになる。