HTTPはステートレス！Webブラウザとサーバー間のセッションを維持する3つの方法

HTTPは「ステートレス（stateless）」なプロトコルです。これは、クライアントがWebページを取得するたびにWebサーバーへの新しい接続が開かれ、サーバー側では以前のクライアントからのリクエスト履歴を自動的には保持しないことを意味します。

そのため、ECサイトのカート機能やログイン状態の保持など、複数のリクエストにまたがってユーザーの状態を扱うには、何らかの仕組みでセッションを維持する必要があります。

Webクライアントとサーバー間でセッションを維持する主な手法

ここでは、代表的な3つの手法と、それぞれのメリット・デメリットを解説します。

1. Cookie（クッキー）

Webサーバーは、各Webクライアントに対して一意のセッションIDをCookieとして割り当てることができます。以降、クライアントからリクエストを受け取るたびに、送信されたCookieを参照することでクライアントを識別できます。

ただし、この方法には弱点があります。ブラウザの設定によってはCookieが無効化されていたり、そもそもサポートされていなかったりする場合があるためです。セッション維持の手段としてCookieのみに依存することは推奨されません。

2. 隠しフォームフィールド（Hidden Form Fields）

Webサーバーは、一意のセッションIDを格納した非表示のHTMLフォームフィールドを、次のようにページに埋め込んで送信できます。

<input type = "hidden" name = "sessionid" value = "12345">

この記述により、フォームが送信される際に、指定されたnameとvalueが自動的にGETまたはPOSTデータへ含まれます。Webブラウザがリクエストを送り返すたびにsession_idの値を利用すれば、異なるブラウザ（ユーザー）を追跡することが可能になります。

セッション追跡の有効な方法ではありますが、通常のハイパーテキストリンク（<A HREF...>）をクリックしてもフォーム送信は発生しないため、この手法だけでは汎用的なセッション管理には対応できません。

3. URLリライティング（URL Rewriting）

各URLの末尾に追加のデータを付加する方法です。このデータによってセッションを識別し、サーバーはそのセッション識別子と、事前に保存しておいたセッション情報を紐付けることができます。

例えば https://tutorialspoint.com/file.htm;sessionid=12345 のように、セッション識別子が sessionid=12345 としてURLに付加され、Webサーバー側でこれを参照してクライアントを特定します。

URLリライティングはセッション維持のためのより堅実な方法で、Cookieをサポートしないブラウザ環境でも動作するのが大きな利点です。ただし欠点として、単純な静的HTMLページであっても、セッションIDを割り当てるためにすべてのURLを動的に生成し直す必要がある点が挙げられます。

まとめ：3つの手法の比較

実際の開発では、これらの手法を状況に応じて組み合わせたり、Java ServletのHttpSessionやトークンベース認証など、フレームワークやプラットフォームが提供するセッション管理機構を利用したりするのが一般的です。