Отслеживание сеанса HTTP
Одно из преимуществ, на которые указывают для динамических языков, должно просто быть в состоянии изменить код и продолжить работать. Никакая потребность перекомпилировать. В 2008 VS.Net, при отладке, можно на самом деле изменить код и продолжить работать без того, чтобы перекомпилировать. С усовершенствованиями в компиляторах и IDE, он возможный, что это и другие преимущества использования динамических языков уйдут.
4 ответа
Как вы упомянули, распространенные способы реализации отслеживания сеансов HTTP включают перезапись URL-адресов и файлы cookie. Отслеживание сеанса в основном требует, чтобы идентификатор сеанса поддерживался для нескольких запросов к серверу. Это означает, что каждый раз, когда данный клиент делает запрос к серверу, он передает один и тот же идентификатор сеанса. Сервер может использовать этот идентификатор для поиска информации о сеансе, которую он поддерживает.
При использовании файлов cookie сервер просит клиента сохранить файл cookie, устанавливая HTTP-заголовок ответа Set-Cookie . Этот файл 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.
Обратите внимание, что сеансы могут истечь. Это означает, что если сервер не «видит» данный идентификатор сеанса в течение определенного периода времени, он может удалить данные сеанса для сохранения ресурсов.
В частности, какая часть HTTP запрос и ответ будут использоваться для отслеживание сеанса?
В HTTP-ответе сервер может установить cookie. Это делается с помощью заголовка Set-Cookie. Например:
Set-Cookie: session=12345; path=/
Затем клиент возвращает значение всех файлов cookie, которые соответствуют свойствам, которые были установлены вместе с файлом cookie, которые могут включать путь (как указано выше) и домен, и срок действия которых еще не истек.
cookie отправляется обратно на сервер как часть заголовков HTTP. Например:
Cookie: session=12345
Никакая исходная информация о свойствах не отправляется обратно с файлом cookie.
Уникальный файл cookie позволяет серверу связать уникальный ключ с конкретным экземпляром браузера. Затем сервер может использовать этот ключ в качестве индекса в хэш-таблице или таблице базы данных, которая содержит уникальную информацию о состоянии каждого пользователя.
обработка сеанса в большинстве случаев осуществляется путем отправки клиенту cookie . этот файл cookie будет отправляться обратно на сервер при каждом запросе от этого конкретного клиента.
Идентификатор сеанса будет связан с некоторыми ресурсами на стороне сервера (файл, пространство RAM), поэтому сервер, прочитав идентификатор сеанса в файле cookie может найти этот ресурс, а затем узнать, какой это был клиент.
Отслеживание сеанса - это вещь на стороне сервера.
Веб-сервер выдает некоторый идентификатор сеанса, который возвращается браузеру. Браузер отправляет этот идентификатор сеанса вместе с каждым запросом.
Вероятно, это делается с использованием файлов cookie прозрачно для пользователя.