» Форма входа

»Мoy-weB ver.4.1

» Статистика

Главная » 2008 » Октябрь » 12 » Формат и синтаксис Cookie

Формат и синтаксис Cookie
12.Окт.2008 | 21:24:41

Формат и синтаксис 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=realcoding.net. В этом случае значение cookie будет
действительно и для сервера realcoding.net, и для www.realcoding.net.
Но не радуйтесь, указания двух последних периодов доменных имен хватает
только для доменов иерархии "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".
Категория: Статьй и уроки | Просмотров: 592 | Добавил: CorsaR
Добавлять комментарии могут только зарегистрированные пользователи.
[ Регистрация | Вход ]