Как работают куки-файлы браузера?

Question

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

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

Позже, когда браузер собирается сделать запрос, он проверяет свои куки-файлы и отфильтровывает те, которые он должен отправить для этого запроса. Это делается путем сопоставления их с путем запросов и доменом. Вопрос 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.

Answer 1

Хотя существует RFC 2965 (Set-Cookie2, уже устарел RFC 2109 ), который должен определять cookie в настоящее время, большинство браузеров этого не делают полностью поддерживаю это, но просто соответствует оригинальной спецификации Netscape .

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

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

Наличие действующего домена также должно domain-match текущий запрашиваемый домен для установки; в противном случае файл cookie будет пересмотрен. То же правило применяется к выбору файлов cookie для отправки в запросе.

---

Для отображения этих знаний на ваши вопросы должно применяться следующее:

• 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.www.example.com ), где .example.com также может быть доступен для любого другого домена ниже example.com (например, foo.example.com или bar.example.com ).

Answer 2

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

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

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

• Исходный домен файла cookie является доменом исходного запроса.

• Если исходный домен является IP-адресом, атрибут домена cookie не должен быть установлен.

• Если атрибут cookie домена не задан, cookie применим только к исходному домену.

• Если установлен атрибут домена cookie,

  • cookie применяется к этому домену и всем его поддоменам;
  • домен куки должен совпадать или быть родителем домена происхождения
  • домен cookie не должен быть ДВУ, общедоступным суффиксом или родителем общедоступного суффикса.

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

Домен 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

Answer 3

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

В соответствии с этим , если на сервере не указан атрибут Domain, пользовательский агент вернет cookie только на исходный сервер (сервер, на котором находится данный ресурс). Но также предупреждение о том, что некоторые существующие пользовательские агенты обрабатывают отсутствующий атрибут Domain так, как если бы атрибут Domain присутствовал и содержал текущее имя хоста (например, если example.com возвращает Set - заголовок Cookies без атрибута Domain, эти пользовательские агенты также будут ошибочно отправлять cookie на www.example.com).

Когда атрибут Domain указан, он будет считаться полным доменным именем (если в атрибуте есть начальная точка, он будет игнорироваться). Сервер должен соответствовать домену, указанному в атрибуте (иметь точно такое же имя домена или быть его поддоменом), чтобы получить этот файл cookie. Точнее это указано здесь .

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

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

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

Answer 4

Для расширенного охвата просмотрите содержание RFC2965 . Конечно, это не обязательно означает, что все браузеры ведут себя одинаково.

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

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

Answer 5

Существуют правила, которые определяют, будет ли браузер принимать заголовок ответа Set-header (запись cookie на стороне сервера), немного другие правила / интерпретации для набора cookie, используя Javascript (я не тестировал VBScript).

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

Существуют различия между основными механизмами браузера в том, как обрабатываются совпадения доменов и как интерпретируются параметры в значениях пути. Вы можете найти некоторые эмпирические доказательства в статье Как разные браузеры по-разному обрабатывают файлы cookie

Answer 6

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

Лучше проверить draft-ietf-httpstate-cookie , работа в процессе.

Answer 7

Я был удивлен, прочитав раздел 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? №

Answer 8

Сможет ли www.example.com установить cookie для .com?

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

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