Андрей
Аликберов, ЦИТ
Спецификация
Синтаксис HTTP заголовка
для поля Cookie
Дополнительные
сведения
Примеры
Спецификация
Полное описание поля Set-Cookie HTTP
заголовка:
Set-Cookie: NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME; secure
Минимальное описание поля Set-Cookie
HTTP заголовка:
Set-Cookie: NAME=VALUE;
NAME=VALUE - строка символов,
исключая перевод строки, запятые и
пробелы. NAME-имя cookie, VALUE - значение.
expires=DATE - время хранения cookie,
т.е. вместо DATE должна стоять дата в
формате Wdy, DD-Mon-YYYY HH:MM:SS GMT, после
которой истекает время хранения
cookie. Если этот атрибут не указан, то
cookie хранится в течение одного
сеанса, до закрытия броузера.
domain=DOMAIN_NAME - домен, для
которого значение cookie
действительно. Например,
domain=cit-forum.com. В этом случае значение
cookie будет действительно и для
сервера cit-forum.com, и для www.cit-forum.com. Но
не радуйтесь, указания двух
последних периодов доменных имен
хватает только для доменов
иерархии "COM", "EDU",
"NET", "ORG", "GOV",
"MIL", и "INT". Для доменов
иерархии "RU" придется
указывать три периода.
Если этот атрибут опущен, то по
умолчанию используется доменное
имя сервера, с которого было
выставлено значение cookie.
path=PATH - этот атрибут
устанавливает подмножество
документов, для которых
действительно значание cookie.
Например, указание path=/win приведет к
тому, что значение cookie будет
действительно для множества
документов в директории /win/, в
директории /wings/ и файлов в текущей
директории с именами типа wind.html и
windows.shtml
Если этот атрибут не указан, то
значение cookie распространяется
только на документы в той же
директории, что и документ, в
котором было установлено cookie.
secure - если стоит такой маркер,
то информация cookie пересылается
только через HTTPS (HTTP с
использованием SSL). Если этот маркер
не указан, то информация
пересылается обычным способом.
Синтаксис HTTP заголовка для поля
Cookie
Когда запрашивается документ с HTTP
сервера, броузер проверяет свои cookie
на предмет соответствия домену
сервера и прочей информации. В
случае, если найдены
удовлетворяющие всем условиям
значения cookie броузер посылает их в
серверу в виде пары имя/значение:
Cookie: NAME1=OPAQUE_STRING1; NAME2=OPAQUE_STRING2 ...
Дополнительные сведения
В случае, если cookie принимает новое
значение при имеющемся уже в
броузере cookie с совпадающими NAME, domain
и path, старое значение затирается
новым. В остальных случаях новые
cookies добавляются.
Использование expires не гарантирует
сохранность cookie в течение
заданного периода времени,
поскольку клиент (броузер) может
удалить запись вследствие нехватки
выделенного места или каких-либо
других лимитов.
Клиент (броузер) имеет следующие
ограничения:
всего может храниться до 300
значений cookies
каждый cookie не может превышать
4Кбайт
с одного сервера или домена
может храниться до 20 значений
cookie
Если ограничение 300 или 20
превышается, то удаляется первая по
времени запись. При превышении 4К -
корректность такого cookie страдает -
отрезается кусок записи (с начала
этой записи) равный превышению.
В случае кэширования документов,
например, proxy-сервером, поле Set-cookie
HTTP заголовка никогда не кэшируется.
Если proxy-сервер принимает ответ,
содержащий поле Set-cookie в заголовке,
предполагается, что поле таки
доходит до клиента вне зависимости
от статуса 304 (Not Modified) или 200 (OK).
Соответственно, если клиентский
запрос содержит в заголовке Cookie, то
он должен дойти до сервера, даже
если установлен If-modified-since.
Я полагаю, что все что
сказано про proxy не относится к
случаю, когда cookie
устанавливается жестко с
помощью META-тагов.
Примеры
Ниже приведено несколько
примеров, иллюстрирующих
использование cookies
Первый пример:
Клиент запрашивает документ и
принимает ответ:
Set-Cookie: CUSTOMER=WILE_E_COYOTE; path=/; expires=Wednesday, 09-Nov-99 23:12:40 GMT
Когда клиент запрашивает URL с
путем "/" на этом сервере, он
посылает:
Cookie: CUSTOMER=WILE_E_COYOTE
Клиент запрашивает документ и
принимает ответ:
Set-Cookie: PART_NUMBER=ROCKET_LAUNCHER_0001; path=/
Когда клиент запрашивает URL с
путем "/" на этом сервере, он
посылает:
Cookie: CUSTOMER=WILE_E_COYOTE; PART_NUMBER=ROCKET_LAUNCHER_0001
Клиент получает:
Set-Cookie: SHIPPING=FEDEX; path=/foo
Когда клиент запрашивает URL с
путем "/" на этом сервере, он
посылает:
Cookie: CUSTOMER=WILE_E_COYOTE; PART_NUMBER=ROCKET_LAUNCHER_0001
Когда клиент запрашивает URL с
путем "/foo" на этом сервере, он
посылает:
Cookie: CUSTOMER=WILE_E_COYOTE; PART_NUMBER=ROCKET_LAUNCHER_0001; SHIPPING=FEDEX
Второй пример:
Клиент принимает:
Set-Cookie: PART_NUMBER=ROCKET_LAUNCHER_0001; path=/
Когда клиент запрашивает URL с
путем "/" на этом сервере, он
посылает:
Cookie: PART_NUMBER=ROCKET_LAUNCHER_0001
Клиент принимает:
Set-Cookie: PART_NUMBER=RIDING_ROCKET_0023; path=/ammo
Когда клиент запрашивает URL с
путем "/ammo" на этом сервере, он
посылает:
Cookie: PART_NUMBER=RIDING_ROCKET_0023; PART_NUMBER=ROCKET_LAUNCHER_0001
Комментарий: здесь мы
имеем две пары имя/значение с
именем "PART_NUMBER".
Это наследие из предыдущего
примера, где значение для пути
"/" прибавилось к значению для
"/ammo".
|