Формат и синтаксис 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 (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".

А.А. Аликберов