Из-за странных проблем с 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 6265 был опубликован в 2011 году на основе консенсуса браузера в то время. С тех пор возникли некоторые сложности с публичными суффиксными доменами. Я написал статью, объясняющую текущую ситуацию - http://bayou.io/draft/cookie.domain.html
Подводя итог, следует соблюдать правила, касающиеся домена cookie:
Домен происхождения из печенья является областью запроса инициирующего.
Если исходным доменом является IP, атрибут 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
источник
x.y.z.com
может установить cookie дляz.com
?Для широкого охвата ознакомьтесь с содержанием RFC2965 . Конечно, это не обязательно означает, что все браузеры ведут себя одинаково.
Однако в целом правило для пути по умолчанию, если в файле cookie не указано иное, является путем в URL-адресе, из которого поступил заголовок Set-Cookie. Точно так же для домена по умолчанию используется полное имя хоста в URL-адресе, с которого поступил файл cookie.
Правила соответствия для домена требуют, чтобы домен cookie соответствовал хосту, к которому выполняется запрос. Файл cookie может указывать более широкое соответствие доменов с помощью include *. в атрибуте домена Set-Cookie (эта область может изменяться браузерами). Сопоставление пути (при условии, что домен совпадает) - это простой вопрос, что запрашиваемый путь должен быть внутри пути, указанного в файле cookie. Обычно сеансовые куки-файлы устанавливаются с помощью пути = / или path = / applicationName /, поэтому cookie-файл доступен для всех запросов в приложении.
Ответ на Добавлено:
*
Я не могу проверить это прямо сейчас, но у меня есть подозрение, что по крайней мере 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. Точнее это указано здесь .
Так, например:
Domain=.example.com
эквивалентенDomain=example.com
Domain=www.example.com
закрывает путь для www4.example.comPS: запятая в атрибуте домена заставит пользовательский агент игнорировать атрибут = (
источник
Я протестировал все случаи в последних Chrome, Firefox, Safari в 2019 году.
Ответ на Добавлено:
источник
Известно, что 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? Нет.
источник
z.com
применяться кz.com
и все поддомены.Нет, но
example.com.fr
может быть в состоянии установить cookie дляexample2.com.fr
. Firefox защищает от этого, поддерживая список TLD: http://securitylabs.websense.com/content/Blogs/3108.aspxСудя по всему, Internet Explorer не позволяет двухбуквенным доменам устанавливать куки, что, я полагаю, объясняет, почему
o2.ie
просто перенаправляет наo2online.ie
. Я часто удивлялся этому.источник