Зачем нужны имя сервера и каталог? Очень просто: дело в том, что сценарию пере- 

даются только те Cookies, у которых параметры с именем сервера и каталога 
совпа- 
дают соответственно с хостом и каталогом сценария (ну, на самом деле каталог не 

должен совпадать полностью, он может являться подкаталогом того, который создан 

для хранения Cookies). Так что совершенно невозможно получить доступ к "чужим" 
Cookies — браузер просто не будет посылать их серверу. Это и понятно: 
представьте 
себе, сколько ненужной информации передавалось бы сценарию, если бы все было не 

так (особенно если пользователь довольно активно посещает различные серверы, 
ко- 
торые не прочь поставить ему свой набор Cookies). Кроме того, дополнительные 
све- 
дения предоставляются в целях защиты информации от несанкционированного дос- 
тупа — ведь в каком-то Cookie может храниться, скажем, важный пароль (как часто 

делается при авторизации), а он должен быть доступен только одному 
определенному 
хосту. 

Глава 3. CGI изнутри 69 
Установка Cookie 
Мы подошли к вопросу: как же сценарий может установить Cookie в браузере 
пользо- 
вателя? Ведь он работает "на одном конце провода", а пользователь — на другом. 
Решение довольно логично: команда установки Cookie — это просто один из 
заголов- 
ков ответа, передаваемых сервером браузеру. То есть, перед тем как выводить 
Content-type, мы можем указать некоторые команды для установки Cookie. Вы- 
глядит такая команда следующим образом (разумеется, как и всякий заголовок, 
запи- 
сывается она в одну строку): 
Set-Cookie: name=value; expires=дата; domain=имя_хоста; path=путь; secure 
Существует и другой подход активизировать Cookie — при помощи HTML-тэга 
. Соответственно, как только браузер увидит такой тэг, он займется 
обработ- 
кой Cookie. Формат тэга такой: 
 
Мы можем видеть, что даже названия параметров в этих двух способах одинаковы. 
Какой из них выбрать — решать вам: если все заголовки уже выведены к тому мо- 
менту, когда вам потребовалось установить Cookie, используйте тэг . В 
про- 
тивном случае лучше взять на вооружение заголовки, т. к. они не видны 
пользовате- 
лю, а чем пользователь меньше видит при просмотре исходного текста страницы в 
браузере — тем лучше нам, программистам. 
Возможно, вы спросите, нахмурив брови: "Что же, с точки зрения программиста 
хороший пользователь — слепой пользователь?" Тогда я отвечу: "Что вы, нет 
и еще раз нет! Такой пользователь хорош лишь для дизайнера, для програм- 
миста же желателен пользователь безрукий (или, по крайней мере, лишенный 
клавиатуры и мыши)". 
Вот что означают параметры Cookie: 
name 
Вместо этой строки нужно задать имя, закрепленное за Cookie. Имя должно быть 
URL-кодированным текстом, т. е. состоять только из алфавитно-цифровых символов. 

Впрочем, обычно имена для Cookies выбираются именно так, чтобы их URL- 
кодированная форма совпадала с оригиналом. 
value 
Текст, который будет рассматриваться как значение Cookie. Важно отметить, что 
этот 
текст (ровно как и строка названия Cookie) должен быть URL-кодирован. Таким об-

Часть I. Основы Web-программирования 70 
разом, я должен отметить неприятный факт, что придется писать еще и функцию 
URL-кодирования (которая, кстати, раза в 2 сложнее, чем функция для декодирова- 

ния, т. к. требует дополнительного выделения памяти). 
expires 
Необязательная пара expires=дата задает время жизни нашего Cookie. Точнее, 
Cookie самоуничтожится, как только наступит указанная дата. Например, если 
задать 
expires=Friday,31-Dec-99 23:59:59 GMT, то "печенье" будет "жить" только до 
31 декабря 1999 года. Кстати, вот вам и вторая неприятность: хорошо, если мы 
знаем 
наверняка время "смерти" Cookie. А если нам нужно его вычислять на основе 
текуще- 
го времени (например, если мы хотим, чтобы Cookie существовал 10 дней после его 

установки, как в подавляющем большинстве случаев и происходит)? Приде