Как вы упомянули, общие способы реализации отслеживания сеанса HTTP включают перезапись URL-адресов и файлы cookie. Отслеживание сеанса в основном требует, чтобы идентификатор сеанса поддерживался в нескольких запросах к серверу. Это означает, что каждый раз, когда данный клиент делает запрос к серверу, он передает один и тот же идентификатор сеанса. Сервер может использовать этот идентификатор для поиска информации о сеансе, которую он поддерживает.
При использовании файлов cookie сервер просит клиента сохранить файл cookie, установив заголовок ответа Set-Cookie HTTP. Этот файл cookie содержит уникальный идентификатор сеанса, назначенный этому клиенту - в этом примере строка «ABAD1D»:
Set-Cookie: JSESSIONID=ABAD1D;path=/
Затем файл cookie отправляется обратно на сервер клиентом, используя заголовок HTTP-запроса Cookie для каждого запроса, и, таким образом, сервер получает информацию о каждом запросе, который в настоящее время назначается клиенту.
Cookie: JSESSIONID=ABAD1D
При использовании перезаписи URL этот же идентификатор сеанса вместо этого отправляется куда-то в URL. Опять же, сервер извлекает идентификатор сеанса из URL, чтобы он мог найти сеанс для конкретного клиента:
http://my.app.com/index.jsp;JSESSIONID=ABAD1D
Однако сервер также должен убедиться, что любые URL-адреса на веб-страницах, отправленных обратно клиенту, также перезаписаны, чтобы содержать этот идентификатор сеанса конкретного клиента. Поскольку идентификатор сеанса закодирован в URL-адресах, этот метод отслеживания сеанса прозрачен для браузера. Часто сервер прибегает к перезаписи URL, если обнаружит, что не может установить cookie-файл сеанса на клиенте, что означает, что клиент не поддерживает / не разрешает использование cookie-файлов.
Обратите внимание, что сессии могут истечь. Это означает, что если сервер не «видит» данный идентификатор сеанса в течение определенного периода времени, он может удалить данные сеанса, чтобы сохранить ресурсы.