Спецификация
Полное описание
поля 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 (Secure Sockets Layer,
протокол защищенных сокетов)). Если этот маркер
не указан, то информация пересылается обычным
способом.
Синтаксис 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".
А.А.
Аликберов
|