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

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

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

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

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

• Будет .example.comли доступен файл cookie для www.example.com?
• Будет .example.comли доступен файл cookie для example.com?
• Будет example.comли доступен файл cookie для www.example.com?
• Будет example.comли доступен файл cookie для anotherexample.com?
• Сможете www.example.comли установить cookie для example.com?
• Сможете www.example.comли установить cookie для www2.example.com?
• Сможете www.example.comли установить cookie для .com?
• И т.п.

Добавлено 2:

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

• Это может быть установлено либо www.example.comили example.com;
• Это доступно как www.example.comи example.com.

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

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

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

Имея действующий домен, он также должен соответствовать текущему запрашиваемому домену для установки; в противном случае файл 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 будет иметь возможность установить печенье для example.com
• www.example.com будет не быть в состоянии установить куки для www2.example.com
• www.example.com будет не быть в состоянии установить куки для .com

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

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

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

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

• Домен происхождения из печенья является областью запроса инициирующего.

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

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

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

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

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

Домен cookie не должен иметь начальную точку, как в .foo.com- просто используйтеfoo.com

Например,

• x.y.z.comможно задать домен куки для себя или родителей - x.y.z.com, y.z.com, z.com. Но нет com, это публичный суффикс.
• печенье с доменом = 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 . Конечно, это не обязательно означает, что все браузеры ведут себя одинаково.

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

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

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

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

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

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

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

Я протестировал все случаи в последних 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? NO . Но он может установить cookie для .example.com, к которому имеет доступ www2.example.com.
• Сможет ли www.example.com установить cookie для .com? НЕТ

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

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

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

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

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

Я был удивлен, прочитав раздел 3.3.2 об отказе от куки:

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

Это говорит о том, что браузер должен отклонить cookie от xyzcom с доменом .z.com, потому что «xy» содержит точку. Так что, если я неправильно истолковываю 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 не позволяет двухбуквенным доменам устанавливать куки, что, я полагаю, объясняет, почему o2.ieпросто перенаправляет на o2online.ie. Я часто удивлялся этому.