Допустим, вы хотите предоставить пользователю возможность просматривать каталог вашей продукции и выбирать из него товары, помещенные на разных страницах. Но "с точки зрения" сервера, выбор товара на одной странице никак не связан ни с предыдущими, ни с последующими действиями того же пользователя. Как же учитывать выбранные пользователем позиции?
Решить эту проблему можно с помощью специального приложения на Web-сервере, которое должно следить за действиями пользователя. Именно эта идея воплощена в технологии идентифицирующих признаков, или - в терминологии Netscape - "плюшек" (cookies). "Плюшки", приготовленные этой компанией, уже стали стандартом де-факто. Но прежде чем мы поближе познакомимся с идентифицирующими признаками, давайте немного подробнее разберемся в сути проблемы.
Взаимоотношения клиентского и серверного ПО во Всемирной паутине достаточно просты. Браузер обращается к серверу с запросом: "Покажи-ка мне такой-то документ". Если указанный документ существует и пользователь имеет право доступа к нему, то сервер выполняет запрос. Вот, в общем-то, и все. Служебная (неинформационная) нагрузка на сеть оказывается очень незначительной, а быстродействие - высоким. Однако при этом возникает одно неудобство: связь между браузером и сервером сохраняется только во время транзакций, причем каждая из них никак не связана с другими. Транзакции такого типа обозначаются специальным термином idempotent (что можно перевести как "равноправные"), а сервер считается не имеющим какого-либо определенного состояния (stateless). Собственно говоря, неудобство возникает только тогда, когда появляется необходимость отследить прохождение сеанса связи, т. е. последовательность запросов конкретного пользователя к Web-серверу.
До того как появились идентифицирующие признаки, единственным способом отслеживания действий посетителя Web-сервера было использование довольно ограниченных возможностей "невидимых полей" в HTML-формах или организация специального процесса обработки "маркеров", встроенных в указатели ресурсов (URL). Как вы понимаете, эти методы неудобны и не слишком надежны.
Что еще за "плюшки"?
Компания Netscape предложила свое решение и включила его в Navigator 0.94, назвав новинку "persistent cookies" (что в буквальном переводе означает нечто вроде "постоянные плюшки". - Прим. пер.). Вместо того чтобы непрерывно передавать данные от браузера к серверу и обратно для поддержания непрерывного же сетевого сеанса, решила Netscape, нужно обеспечить Web-серверу возможность помещать в файловую систему браузера и впоследствии считывать оттуда небольшое количество служебной информации ("плюшку"). Данные, хранящиеся в "плюшке", или признаке, могут, например, идентифицировать пользователя, сеанс связи (который отслеживается при отсутствии сведений об осуществляющем его пользователе) или какие-либо другие показатели по желанию администратора Web-сервера.
Для того чтобы сделать процесс записи и считывания меток состояния "прозрачным" для пользователя, Netscape разработала расширение к протоколу HTTP, который является неотъемлемой частью Всемирной паутины. Вообще говоря, протокол HTTP достаточно прост. Когда браузер обращается к серверу с запросом, тот посылает в ответ запрашиваемые данные, которые предваряются некоторой маркировкой, состоящей из набора служебных меток. Если сервер намеревается заложить в клиентское ПО "плюшку", то в маркировку включается метка "Set cookie" (более подробно об этом рассказывается во врезке).
Хранение идентифицирующих признаков
Форма записи идентифицирующих признаков определяется разработчиками браузера и связана с используемой операционной системой. "Плюшки" поддерживаются большинством версий Netscape Navigator (начиная с 0.94), Internet Explorer компании Microsoft и несколькими другими браузерами (их список можно найти по адресу research.digital.com/nsl/formtest/).
Спецификация фирмы Netscape позволяет браузеру хранить до 300 признаков, каждый из которых может иметь размер до 4 Кбайт. Предусмотрен также лимит в 20 признаков на любой сервер или домен. В спецификации указывается, что серверы "не должны рассчитывать на возможность превышения лимита. Если же это происходит, клиентское ПО должно удалить наиболее старые признаки".
В браузере Netscape Navigator файл с признаками (cookies.txt) хранится в одном из подкаталогов. Формат этого файла запатентован, и если вы не хотите испортить содержащуюся в нем информацию, то не стоит пытаться его редактировать (при этом средства защиты файла не предусмотрены). Различные браузеры и операционные системы хранят признаки по-своему. Например, в программе Navigator для Macintosh они записываются в папку Navigator, а в Internet Explorer - в подкаталог в виде макрокоманд.
Здесь стоит отметить, что имена и значения признаков присваиваются сервером, и в абсолютном большинстве случаев содержание признака ничего не говорит пользователю браузера.
Процесс идентификации
Возникает вопрос: а зачем серверу могут понадобиться идентифицирующие признаки? Схематически работу с "плюшками" можно представить следующим образом. Например, чтобы организовать показ страниц Web-сервера в соответствии с предпочтениями пользователя, сервер помещает соответствующую информацию в браузер в виде признаков. При каждом обращении браузера к серверу последний считывает данные из "плюшки" и отображает нужные пользователю страницы.
Но на самом деле сервер не считывает эту информацию. Просто браузер, обращаясь к ресурсу на сервере в определенном домене, прежде всего ищет в своем файле с идентифицирующими признаками действующие "плюшки" (т. е. те, срок годности которых не истек), предназначенные для этого ресурса или соответствующего сервера. Если для данного сервера такие признаки находятся, то браузер помещает в начало запроса маркировочную метку HTTP_COOKIE, имя и дату записи признака. Приложение на Web-сервере автоматически считывает эту информацию с помощью CGI-интерфейса.
Часто спрашивают: а не может ли идентифицирующий признак каким-либо образом сообщить серверу содержание жесткого диска пользователя или другую конфиденциальную информацию? Ответ однозначен: не может. От клиента к серверу и обратно передается только содержание признака. Никакая другая информация о клиенте для сервера недоступна. Однако если вы собираетесь использовать идентифицирующие признаки для отслеживания действий пользователей, вполне разумно шифровать их содержимое, чтобы информация, принадлежащая вам, не могла быть прочитана на клиентской машине. Еще лучше, если вы будете пересылать туда не сами данные, а указатели на признаки, помещенные в базе данных сервера. Вам придется передавать эти данные на клиентскую машину только в том случае, если признаки предназначены для другого сервера. Такой прием может оказаться полезным в интрасети, когда нужно следить за действиями пользователей на всех ее серверах.
Стандартизация "плюшек"
Сегодня идентифицирующие признаки, или "плюшки", являются стандартом de facto, но недалек тот день, когда они станут им de jure. Сейчас в Рабочей группе инженеров Internet (IETF) находится на рассмотрении проект стандарта на "плюшки", имеющий очень серьезное название "HTTP State Management Mechanism" (подробности см. portal.research.belllabs.com/et).
При разговоре об этой технологии неизбежно возникает еще один вопрос: почему Netscape назвала идентификационные признаки "плюшками"? Хотя с их помощью мы можем пролить свет на то, как пользователи эксплуатируют сервер, загадка самого названия, вероятно, навсегда останется тайной. Представители Netscape утверждают, что за ним "ничего особенного не скрывается". Таков уж мир современных компьютерных технологий!
Рецепт изготовления "плюшек"
Маркировка "Set-Cookie" имеет следующий вид:
Set-Cookie: NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME; secure
NAME и VALUE - любые строковые переменные, с помощью которых происходит идентификация пользователя. Переменные не должны содержать точек с запятой, запятых либо пробелов. Пара NAME=VALUE является единственным обязательным элементом маркировки.
Переменная DATE указывает дату, после которой признак должен быть автоматически удален. Если дата не указана, то метка будет существовать только до конца текущего сеанса работы с браузером Navigator.
Переменная PATH указывает полный или частичный адрес страницы (URL), для которой признак является действительным. Например, для адреса http://www.gibbs.com/somestuff/mydoc.html будет действительным признак, предназначенный для домена "www.gibbs.com" и содержащий путь "/some,".
Метка DOMAIN_NAME описывает имя домена, к которому относится данный признак. Если эта метка не задана, то значением по умолчанию является имя сервера, создавшего маркировку признака.
Метка "secure" указывает на то, что передача признака серверу может осуществляться только в зашифрованном виде.
Следует иметь в виду, что под одной маркировкой может "издаваться" несколько признаков, но в этом случае они должны относиться к разным ресурсам (URL) и иметь разные пути. В противном случае на клиентской машине будет установлен последний из идентичных признаков.
Более подробную информацию об идентифицирующих признаках можно найти в документе " Netscape HTTP Cookie Notes" по адресу illuminatus.com/cookie/fcgi.