■ セッションステートレス

さて、ネット君。HTTPの基本動作、リクエストとレスポンスについては大体説明したわけだ。

はい、メソッドと、ステータスコードですよね。

まぁ、それだけではないが、いいだろう。
メソッドでどのような要求かを伝え、それに対する応答をステータスコードで伝える。もちろんデータのやりとりもあるわけだ。

はいはい、でしたよ。

さて、ここで思い出して欲しいのは、セッションという言葉だ。

せっしょん？
OSIモデルのレイヤ5ですか？

うむ、第49回で説明したセッション層のセッションだ。
どういう意味だった？

プロセス間の話し合いの管理だと。

そうだ。つまり「要求元」プロセスと、「宛先」プロセスがお互いを認識し、データのやりとりを行うわけだ。
データのやりとりは一連の流れとして管理される。

でしたね。

セッションの開始と切断は、「データ転送の開始と終了」を意味する。

コネクションは「データ転送用回線の接続・切断」で、複数のコネクションで１つのセッションを作るんでしたよね。

そうだ。つまり、データのやりとりはセッション単位で管理される。 逆に言えば、セッションが違えば、管理はできない、ということになるな。

そうなりますね。

さて、ここで問題になるのは、HTTPでは1ページのやりとりが1つのセッションなのだよ。

はぁ。

何処が問題かわかってないようだな？

ページのやりとりが1セッション。
何か問題が？

こういうことだ。

前のセッションとは別物……、何か問題が？

いつも言ってることだが、もうちょっと想像したまえ。
サーバは前のアクセスの状態を記憶できないと言ってるのだぞ。

はぁ。

あ〜、じれったい。つまり、こういうことだ。

このように、初めてのアクセスのユーザと、2回目以降のアクセスのユーザでページを別にしたい場合、どこで判断するのだ？

あ〜、なるほど。そういえばそうですね。

相変わらずその鈍さには感服する。

えへへ。

褒めてねぇ。

はぅっ。

ともかくだ、同一のセッションならば「同じ相手からのアクセス」だと認識できるが、一度セッションが切断されてしまうと、前のことは覚えていられないのだよ。ネット君のように。

は〜。アクセスしてきたホストが前のホストかどうかわからないのですね、僕のように。
…………僕のように、ってのはとても納得がいかないのですが？

そうか？ 我ながら賞賛に値する比喩だと思ったのだが。
ともかく、これをHTTPのセッションステートレス問題という。

せっしょんすてーとれす？

セッションの状態（ステート）を保持しない（レス）なわけだな。

あ〜、前にアクセスしたという「状態」を覚えていない、という意味ですか。

■ Cookie

このサーバは前のセッションと今回のセッションが同一のホストからのものか識別できないというセッションステートレス問題だが。
ショッピングサイトなどのサイトでは結構困るわけだ。

ショッピングサイト？
あ〜、「買い物カゴ」とかですか？

うむ。「買い物カゴ」に前のページで買った品物がないと、何が「買い物カゴ」だ、という話になるな。
だが、通常のHTTPではページが切り替わった時点でセッションが切断され、前の状態は保存されなくなる。

ってことは、「買い物カゴ」はページが切り替わるたびに真っ白になるんですね。
それは見事に意味がないですね。

なので、何とかして「今アクセスしているホストは前回アクセスしてきたホストと同一だ」と識別させなければならない。
さてどうする？

どうすると言われましても。

ふむ。例えば、客の顔を覚えられないネット君のような店員がいるビデオレンタル店があるとする。
さて、この店と店員は来た客が会員かどうかどうやって判断する？

「僕のような」という形容詞はどうかと思いますが。
そうですね、普通は会員証を見せてもらいますよね。

そう、最初に来た時点で「会員証」を渡し、以降その「会員証」を見せてもらうことで、「前回来た客だ」ということを識別するわけだ。

……つまり、最初のアクセス時に「会員証」を渡して。
それ以降のアクセスでは「会員証」を見せてもらえばいいんですね？

そういうことだ。
この「会員証」をCookieと呼ぶ。

くっきー？
あの、お菓子のクッキー？

そうだ。ネットスケープ社がそう名付けたのだ。
実を言うと、このCookie、正式な標準規格ではない。▼ link

そうなんですか？

ネットスケープ社が開発し、その後それが広まって業界標準になったという代物だ。
さて、そのCookieがどのように使われるかだが。▼ link

はい。

先ほどの「会員証」の流れを思い出しつつ、以下の図を見てもらおう。

は〜。「会員証」を渡す、わけですね。それがCookieだ、と。

そうだ。まず、識別用の値などと共にCookieを作るようにサーバからクライアントへレスポンスが返るわけだ。

え〜っと、それって、Cookieを作らせるためだけに送るんですか？

ん？ あぁ、データを返す時に一緒にだ。
「これが要求したページのデータです。それとこの値のCookieを作ってください」と返すわけだな。

なるほど。

つまり、このCookieを使うことにより擬似的にセッションを作り出すことができるわけだ。

擬似的にセッション……。

Cookieのおかげで前回のアクセスと、今回のアクセスが同一のホストだとわかるわけだろう？
つまり、前回のセッションの「続き」が可能になるわけだ。

あ、なるほど。2つのセッションがつながってるように見せかけることができるわけですね。

そういうことだ。
さて、この時HTTPで使用するのは「Set-Cookie」メッセージヘッダだ。

せっとくっきー？
え〜っと、第73回の一覧表にはなかったですよ？

だから、ネットスケープ社が作ったといっただろう。
一方、クライアントからCookieの内容を送る時は「Cookie」メッセージヘッダを使う。

ははぁ。レスポンスの「Set-Cookie」の後ろに書いてある内容が識別情報なんですね。

そういうことだ。
次に同じサイトを見に行く場合、リクエストには「Cookie」の後ろにその識別情報を入れるわけだ。

なるほどなるほど。

■ Cookieの中身

さて「会員証」たるCookieだが、その中身に何が書かれているかというと。

いうと？

1つだけ書くことが決められている。その他はサーバが任意に決める。

たった1つだけですか？

そうだ。それ以外は任意だ。
その1つの必須のものは、Cookieの名前だ。

名前？

うむ。なお、Set-Cookie、Cookieメッセージヘッダには以下のように値が記入される。

なんとか イコール なんとかの値 セミコロン、ですか？

そういうことだ。

へ〜。

基本的には以下のようなものをCookieには書くことになっている。
ただし、最初の名前以外はすべて必要なものだけ書けばいいことになっている。

名前、有効期限はわかるけど、パス属性？ サーバドメイン名？

それについては順に説明していく。
例えば、以下のようになっていた場合。

これを先ほどのもの説明で解説すると。

こうなる。

は〜。
名前は必ずuseridなんですか？

いや、名前の名前、つまりCookieの名前と、その値は好きにつけることができる。
この場合名前としてuserid、その値として123とした、ということだな。

その他のサーバが処理に必要な識別情報ってのは1つだけしか駄目なんですか？

この例では1つだが、好きなだけつけることができる。
「username = prof ; job = teacher ; country = japan ; …」など可能だ。

処理に必要なら必要な分OKってことですね。

そういうことだな。

なるほど。

■ Expire

Cookieは、もしCookieの中身にExpireがあった場合、ファイルとして保存される。
保存される場所は、InternetExplorerなら、「\Documents and Settings\（ユーザ名）\Local Settings\Temporary Internet Files」になる。

ファイルとして保存されるんですか？
じゃあ、中を見ることができますね。

うむ、中を見たい時、手っ取り早いのは以下の方法だな。

インターネットオプションって、IEの「ツール」の「オプション」でしたっけ？

露骨な説明ありがとう。たまには助手らしいことをするな。
ま、ともかく「インターネットオプション」で「インターネット一時ファイル」の「設定」の「ファイルの表示」でその保存先フォルダを見ることが出来る。

へ〜………。
なんか、開くと一杯ファイルがありますよ？ どれです？

「インターネットアドレス」のところが「Cookie」で始まるファイルだ。
このようにExpireが指定されていた場合、保存されることになる。

指定された場合？ 指定されない場合は保存されないんですか？

そうだ。Expireがない場合はファイルとして保存されずにブラウザが閉じるまでしか使われない。
これはセッションCookieと呼ばれる。

このような動作になる。

つまり、同じブラウザで同じサーバにアクセスしている時だけ使うことができるわけですね？

そういうことだな。その一連のやり取り（セッション）だけしか使えないから「セッションCookie」というわけだ。

へ〜。でも、ずっと保存しておいたっていいのに。

そう思うのも無理はないが、ファイルとして保存しておいて、後でも再利用可能にしておくとセキュリティ上問題がある。クロスサイトスクリプティングなどによりそのCookieが奪われてしまうことがある。▼ link

盗まれちゃうんですか？

そうだ。なので、重要なものを情報としてCookieとして使う場合は、セッションCookieにして保存しないのがお約束だ。

重要なものって？

名前、住所、電話番号、クレジットカード番号、パスワード、その他もろもろだな。

あ〜、それは確かに盗まれると困りますよねぇ。

■ PathとDomain

さて、Cookieの中身についてもう１つ話そう。
サーバからSet-Cookieとして書かれている情報を、Cookieで送り返すわけなんだが。

はい。

どのサーバに送り返すか、という問題点がある。
つまり、Set-Cookieを送ってきたサーバにのみ、Cookieを返さなければならない。

そりゃそうですね。全然関係のないサーバにCookieを送ったって意味ないですもんね。

うむ、そうだろう。それを識別する値がDomainなのだよ。
このDomainに書かれたドメイン名を持つサーバに対してのみそのCookieを返す。

上の例の場合、Set-CookieのDomainの値が「www.3min.net」なので、そのサーバにはCookieを送るが、「www.30min.com」には送らない、ということだな。

なるほど。

ただし、以下のような場合はOKだ。

Domainが3min.co.jpの場合、www.3min.co.jpとwww2.3min.co.jpならOK？
ドメイン名があってればOKってことですか？

ドメイン名があっていれば、というか。
ドメイン名の後ろから確認していって、一致すれば、だな。

ドメイン名を後ろから…、あ〜、なるほど。
なんか後ろから確認していくなんてDNSみたいですね。

まぁ、確かに似ているな。
それともう１つある。サーバのドメイン名が同じでも、サイトが違う場合がある。

サイト？

つまり、「http://www.3min.net/net/」と「http://www.3min.net/emi/」では別人のサイトの可能性があるだろう？
それなのにサーバのドメイン名が同じだから、とCookieを送ってしまってはまずいだろう。

それもそうですね。

よって、Pathに書かれたURIを持つサイトに対してのみそのCookieを返す形にする。

ドメイン名の後ろの部分とPathが一致しないと駄目なんですね。

そういうことだ。なお、Pathが「/」だけの場合は、そのサーバすべてのサイトという意味になる。
また、先ほど同様、「Path = /net/」でも、「/net/study」や「/net/diary」のような下位フォルダには送ることになる。

ははぁ、考えられてますねぇ。

もし、DomainやPathがSet-Cookieで省略されていた場合、クライアントは保存する際にそのサーバのドメイン名をDomainに、そのサイトをPathに自動的に入れて保存する。

なるほど、省略されたからと言って無差別に送るわけではないんですね。

今回はこのぐらいにしておこう。

はい。

もうちょっとHTTPの話が続くぞ。

多いですね、HTTP。

そうだな、現在最も人気のあるプロトコルだからな。利用法も多いのだよ。
では、また次回。

了解です。 ３分間ネットワーキングでした〜♪