Поддержка состояния сеанса

Протокол передачи гипертекстовых файлов HTTP — это протокол без установления соединения. Впрочем, ATL Server имеет возможность поддерживать для каждого клиента состояние сеанса между следующими друг за другом HTTP-запросами Это достигается с помощью cookie-файлов, предназначенных для сохранения данных о каждом клиентском сеансе. ATL Server может с помощью соответствующего cookie-файла получать данные о состоянии каждого клиентского сеанса.

Вначале cookie-файл создается расширением интерфейса прикладного программирования Internet-сервера (ISAPI). Он содержит пару, состоящую из имени и строкового значения. Затем эта пара передается клиенту в заголовке HTTP-ответа. Каждый cookie-файл дает возможность Web-серверу сохранять на Web-броузере тот или иной фрагмент информации, который впоследствии будет передаваться снова на сервер в заголовке каждого HTTP-запроса, направляемого по соответствующему унифицированному указателю информационного ресурса (URL).

Для удобства работы с cookie-файлами ATL Server предоставляет класс CCookie. Этот класс можно использовать для инкапсуляции cookie-файлов, содержащих одно значение или целый их набор.
Вот пример, который показывает, как сконструировать два простых метода замены, называемых SendCookieToClient (отправить cookie-файл клиенту) и GetCookieFromClient (получить cookie-файл от клиента). В примере используется cookie-файл с одним значением, который инкапсулирует имя nameOfCookie (имя cookie-файла) и значение, содержащее простое строковое представление текущего времени.

// Обработчик, который посылает cookie клиенту
[request_handler("send_cookie_to_client")]
class C_send_cookie_to_client_AppHandler
{
protected: // защищенный
[ tag_name(name="SendCookieToClient") ]
HTTP_CODE SendCookieToClient(void)
{
CString valueOfCookie;
SYSTEMTIME systemTime;
GetLocalTime(SsystemTime);
valueOfCookie.Format( // Формат
"%d:%d", systemTime.wHour, systemTime.wMinute);
CCookie cookie;
cookie.SetName("nameOfCookie");
cookie.SetValue(valueOfCookie);
cookie.SetPath("/"); //URL где применяется cookie
m_HttpResponse.AppendCookie(&cookie);
// указать, что мы послали cookie клиенту
m_HttpResponse
<< "SendCookieToClient sent: " // послать
<< valueOfCookie;
return HTTP_SUCCESS;
}
};
// Обработчик, который получает cookie от клиента
[request_handler("get_cookie_from_client")]
class C_get_cookie_from_client_AppHandler
{
protected: // защищенный
[ tag_name(name="GetCookieFromClient") ]
HTTP_CODE GetCookieFromClient(void)
{
CString valueOfCookie;
CCookie cookie =
m_HttpRequest.Cookies("nameOfCookie");
BOOL bSuccess = cookie.GetValue(valueOfCookie);
// ЛОГИЧЕСКОЕ ЗНАЧЕНИЕ
if (bSuccess)
{
// доказать, отображая cookie, что мы его получили
m_HttpResponse
<< "Proof that GetCookieFromClient worked: "
// <<"Доказательство, что работал
// GetCookieFromClient: "
<< valueOfCookie;
}
return HTTP_SUCCESS;
}

Соответствующие файлы send_cookie_to_client.srf и get_cookie_ f rom_client. srf взаимодействуют с Web-броузером для обмена информацией, которая хранится на клиентском компьютере в виде cookie-файла
Вначале Web-броузер получает доступ к файлу send_cookie_to_client. srf Этот srf-файл указывает метод замены, называемый SendCookieToClient, который создает и отправляет cookie-файл на Web-броузер

{{handler ATLServerApp.dll/send_cookie_to_client}}
{{SendCookieToClient}}

Затем Web-броузер получает доступ к файлу get_cookie_f rom_client. sr f А этот srf-файл указывает метод замены, называемый GetCookieFromClient, который, в свою очередь, принимает cookie-файл от клиента

{{handler ATLServerApp.dll/get_cookie_from_elient}}
{{GetCookieFromClient}}

Результат выполнения этого примера можно увидеть, перейдя вначале по унифицированному указателю информационного ресурса (URL) туда, откуда cookie-файл передается клиенту, а затем перейдя по унифицированному указателю информационного ресурса (URL) туда, куда cookie-файл передается от клиента Немного поэкспериментировав, вы увидите, что с cookie-файлом не происходит никаких изменений до тех пор, пока вы снова не перейдете по тому унифицированному указателю информационного ресурса (URL), откуда cookie-файл должен отправиться к клиенту Вот эти URL-адреса

• http://localhost/ATLServerApp/send_cookie_to_client.srf,
• http://localhost/ATLServerApp/get_cookie_from_client.srf

Результат перехода в Internet Explorer по первому унифицированному указателю информационного ресурса (URL) показан на рис 12 15, а по второму — на рис. 12.16.

Рис. 12.15. Просмотр send_cookie_to_client srf.

Рис. 12.16. Просмотр get_cookie_from_chent srf

Это пример немного надуманный, но он прямо и просто показывает, каким образом работают cookie-файлы. Главное в нем — не реализм, а рабочий механизм таких файлов. В данном примере файл send_cookie_to_client. srf создает cookie-файл, содержащий текущее время, что было бы несколько необычно для приложения из реальной жизни. Затем файл get_cookie_from_client.srf отправляет HTML-код, который отображает содержимое cookie-файла, причем только как доказательство того, что этот файл работает Ну, так это и вовсе нетипично.
Более реалистичное приложение должно использовать cookie-файлы для хранения более полезной информации, такой, например, как предпочтения пользователя и нестандартные настройки страниц. Когда пользователь впервые посещает Web-страницу, то некоторую информацию можно получить с помощью формы. Получив информацию, сервер "укладывает" ее в один или несколько cookie-файлов и отправляет их на Web-клиент. Затем при последующих посещениях клиентом других страниц на том же самом Web-узле сервер может извлекать эти cookie-файлы, выбирать содержащуюся в них информацию и на ее основе настраивать генерируемый им HTML-код.