Как работать с доменами cookie браузера?
========================================

Из-за странных проблем с файлом cookie домена/субдомена, который я получаю, я хотел бы знать, как браузеры обрабатывают файлы cookie. Если они делают это по-разному, было бы неплохо узнать различия.

Другими словами - когда браузер получает файл cookie, этот файл cookie может иметь домен и путь, прикрепленный к нему. Или нет, и в этом случае браузер, вероятно, заменяет некоторые значения по умолчанию для них. Вопрос 1: что это такое?

Позже, когда браузер собирается сделать запрос, он проверяет свои файлы cookie и отфильтровывает те, которые он должен отправить для этого запроса. Он делает это, сопоставляя их с запросами пути и домена. Вопрос 2: какие правила соответствия?

---

 **Добавлено:**
Причина, по которой я спрашиваю об этом, - это то, что меня интересуют некоторые случаи краев. Как:

* Будет ли доступен файл cookie для `.example.com` для `www.example.com`?
* Будет ли доступен файл cookie для `.example.com` для `example.com`?
* Будет ли доступен файл cookie для `example.com` для `www.example.com`?
* Будет ли доступен файл cookie для `example.com` для `anotherexample.com`?
* Будет ли `www.example.com` установить cookie для `example.com`?
* Будет ли `www.example.com` установить cookie для `www2.example.com`?
* Будет ли `www.example.com` установить cookie для `.com`?
* Etc.

  **Добавлен 2:**

Кроме того, может кто-нибудь предложить, как я должен установить cookie, чтобы:

* Его можно установить либо с помощью `www.example.com`, либо `example.com`;
* Доступно как с помощью `www.example.com`, так и `example.com`.

 

Существует различие между значением атрибута Domain и эффективным доменом: первое берется из поля заголовка `Set-Cookie`, а второе - интерпретацией этого значения атрибута. Согласно RFC 2965, должно применяться следующее:

* Если в поле заголовка Set-Cookie  **нет** есть атрибут домена, то эффективным доменом является домен запроса.
* Если присутствует атрибут домена, его значение будет использоваться как эффективный домен (если значение не начинается с `.`, оно будет добавлено клиентом).

Имея эффективный домен, он должен также [domain-match](http://tools.ietf.org/html/rfc6265#section-5.1.3) текущий запрашиваемый домен для установки; иначе cookie будет пересмотрен. Это же правило применяется для выбора файлов cookie, отправляемых в запросе.

 .i1a { width: 336px; height: 280px; }
 @media(min-width: 768px) { .i1a { width: 728px; height: 90px; } }
 @media(min-width: 992px) { .i1a { width: 360px; height: 300px; } }
 @media(min-width: 1083px) { .i1a { width: 728px; height: 90px; } }

 (adsbygoogle = window.adsbygoogle || []).push({});

---

Сопоставляя эти знания на свои вопросы, следует применять следующее:

* Cookie с `Domain=.example.com`  **будет** доступен для www.example.com
* Cookie с `Domain=.example.com`  **будет** доступен для example.com
* Cookie с `Domain=example.com` будет преобразован в `.example.com`, и таким образом  **будет** также доступен для www.example.com
* Cookie с `Domain=example.com` будет  **не** доступен для anotherexample.com
* www.example.com  **будет** иметь возможность устанавливать cookie для example.com
* www.example.com  **не** сможет установить cookie для www2.example.com
* www.example.com будет  **не** уметь устанавливать cookie для .com

И чтобы установить и прочитать файл cookie для/на www.example.com и example.com, установите его для `.www.example.com` и `.example.com` соответственно. Но первый (`.www.example.com`) будет доступен только для других доменов ниже этого домена (например, foo.www.example.com или bar.ww..example.com), где `.example.com` можно также получить в любом другом домене ниже примера .com(например, foo.example.com или bar.example.com).

 

Предыдущие ответы немного устарели.

 [RFC 6265](http://tools.ietf.org/html/rfc6265) был опубликован в 2011 году на основе консенсуса браузера в то время.
С тех пор было некоторое усложнение с общедоступными доменами суффикса. Я написал статью, объясняющую текущую ситуацию - <http://bayou.io/draft/cookie.domain.html>

Подводя итог, правила, которые следует соблюдать в отношении домена cookie:

* Происхождение домена cookie является доменом исходного запроса.
* Если исходный домен является IP, атрибут домена cookie не должен быть установлен.
* Если атрибут домена cookie не установлен, cookie применим только к его исходному домену.
* Если установлен атрибут домена cookie,

	+ cookie применим к этому домену и ко всем его поддоменам;
	+ домен cookie должен быть таким же, как или родительский, домен происхождения
	+ домен cookie не должен быть TLD, открытым суффиксом или родителем открытого суффикса.

Можно получить, что cookie всегда применим к его исходному домену.

 .i2a { width: 336px; height: 280px; }
 @media(min-width: 768px) { .i2a { width: 728px; height: 90px; } }
 @media(min-width: 992px) { .i2a { width: 360px; height: 300px; } }
 @media(min-width: 1083px) { .i2a { width: 728px; height: 90px; } }

 (adsbygoogle = window.adsbygoogle || []).push({});

В домене cookie не должно быть ведущей точки, как в `.foo.com` - просто используйте `foo.com`

В качестве примера,

* `x.y.z.com` может установить домен cookie для себя или родителей - `x.y.z.com`, `y.z.com`, `z.com`. Но не `com`, который является публичным суффиксом.
* cookie с доменом = `y.z.com` применим к `y.z.com`, `x.y.z.com`, `a.x.y.z.com` и т.д.

Примеры публичных суффиксов - `com`, `edu`, `uk`, `co.uk`, `blogspot.com`, `compute.amazonaws.com`

 

Для обширного обзора покрытия содержимое [RFC2965](http://tools.ietf.org/html/rfc2965). Конечно, это не обязательно означает, что все браузеры ведут себя точно так же.

Однако правило правила для Пути по умолчанию, если ни один из указанных в cookie не является адресом в URL-адресе, из которого появился заголовок Set-Cookie. Точно так же по умолчанию для Домена указано полное имя хоста в URL-адресе, из которого прибыло Set-Cookie.

Правила сопоставления домена требуют, чтобы домен cookie соответствовал хосту, на который делается запрос. Файл cookie может указывать более широкое совпадение доменов include *. в атрибуте домена Set-Cookie (эта область, в которой браузеры могут отличаться). Согласование пути (при совпадении с доменом) является простым вопросом, что запрошенный путь должен находиться внутри пути, указанного в файле cookie. Обычно файлы cookie сеанса задаются с помощью path =/или path =/applicationName/, поэтому cookie доступен для всех запросов в приложении.

 

---

 **Ответ на добавленный:**
* Будет ли доступен файл cookie для .example.com для www.example.com?  **Да**
* Будет ли файл cookie для .example.com доступен для example.com?  **Не знаю**
* Будет ли файл cookie для example.com доступен для www.example.com?  **Должен не...** *
* Будет ли cookie для example.com доступен для anotherexample.com?  **Нет**
* Может ли www.example.com установить cookie для example.com?  **Да**
* Может ли www.example.com установить cookie для www2.example.com?  **Нет** (кроме как через .example.com)
* Может ли www.example.com установить cookie для .com?  **Нет** (Невозможно установить cookie в этом пространстве имен, и вы не можете установить его для чего-то вроде .co.uk).

 `*` Я не могу проверить это прямо сейчас, но у меня есть подозрение, что по крайней мере IE7/6 будет рассматривать путь `example.com`, как если бы он был `.example.com`.

 

Последним (точнее третьим) RFC для этой проблемы является RFC-6265 (устаревшие RFC-2965, которые, в свою очередь, устаревшие RFC-2109).

[В соответствии с этим](http://tools.ietf.org/html/rfc6265#section-4.1.2.3), если сервер пропускает атрибут "Домен", пользовательский агент будет возвращать cookie только на **исходный сервер** (сервер, на котором находится данный ресурс). Но также **предупреждает**, что некоторые существующие пользовательские агенты обрабатывают отсутствующий атрибут Domain так, как если бы атрибут Domain присутствовал и содержал текущее имя хоста (например, если example.com возвращает заголовок Set-Cookie без домена атрибуты, эти пользовательские агенты также будут по ошибке отправлять куки на www.example.com).

Если указан атрибут "Домен", он будет считаться полным доменным именем (если в атрибуте есть начальная точка, он будет игнорироваться). Сервер должен соответствовать домену, указанному в атрибуте (иметь точно такое же имя домена или быть его поддоменом), чтобы получить этот файл cookie. Точнее это [указано здесь](http://tools.ietf.org/html/rfc6265#section-5.1.3).

Так, например:

* атрибут cookie `Domain=.example.com` эквивалентен `Domain=example.com`
* файлы cookie с такими атрибутами домена будут **доступны** для example.com и www.example.com
* .файлы cookie с такими атрибутами домена будут **недоступны** для другого сайта-примера
* указание атрибута cookie, например `Domain=www.example.com`, закроет путь для www4.example.com

PS: запятая в атрибуте Domain заставит пользовательский агент игнорировать атрибут = (



RFC, как известно, не отражают реальность.

Лучше проверить [draft-ietf-httpstate-cookie](http://tools.ietf.org/html/draft-ietf-httpstate-cookie-08), работа выполняется.

 

Затем существуют правила, определяющие, будет ли браузер отправлять cookie вместе с запросом страницы.

 

Я протестировал все случаи в последних версиях Chrome, Firefox, Safari в 2019 году.

**Ответ на Добавлено:**

* Будет ли файл cookie для .example.com доступен для www.example.com? **ДА**
* Будет ли файл cookie для .example.com доступен для example.com? **ДА**
* Будет ли файл cookie для example.com доступен для www.example.com? **НЕТ**, домен без подстановочных знаков совпадает только сам по себе.
* Будет ли файл cookie для example.com доступен для anotherexample.com? **НЕТ**
* Сможет ли www.example.com установить cookie для example.com? **НЕТ**, он сможет установить cookie для ".example.com", но не "example.com".
* Сможет ли www.example.com установить cookie для www2.example.com? **НЕТ**. Но он может установить cookie для .example.com, к которому имеет доступ www2.example.com.
* Сможет ли www.example.com установить cookie для .com? **НЕТ**



Я с удивлением прочитал раздел 3.3.2 об отказе от куки файлов:

 <http://tools.ietf.org/html/rfc2965>

Это говорит о том, что браузер должен отклонить файл cookie с сайта x.y.z.com с доменом .z.com, потому что "x.y" содержит точку. Итак, если я не неправильно интерпретирую RFC и/или вопросы выше, могут быть добавлены вопросы:

Будет ли доступен файл cookie для .example.com для www.yyy.example.com? Нет.

Будет ли файл cookie, установленный сервером происхождения www.yyy.example.com, с доменом .example.com, имеет ли значение, отправленное агентом пользователя, на xxx.example.com? Нет.

 

>  Будет ли `www.example.com` установить cookie для `.com`?
> 
> 
> 

Нет, но `example.com.fr` может установить cookie для `example2.com.fr`. Firefox защищает от этого, поддерживая список TLD: <http://securitylabs.websense.com/content/Blogs/3108.aspx>

Очевидно, что Internet Explorer не разрешает двухбуквенным доменам устанавливать файлы cookie, что, я полагаю, объясняет, почему `o2.ie` просто перенаправляется на `o2online.ie`. Я часто задавался этим вопросом.