Как работают Домены cookie браузера?

из-за странных проблем с файлами 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:

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

  • он может быть установлен либо www.example.com или example.com;
  • он доступен как www.example.com и example.com.
8 305
path http cookies dns rules

8 ответов:

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

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

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

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

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

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

и установить и прочитать cookie для/by 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).

309

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

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

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

  • The происхождения домен cookie-это домен исходного запроса.

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

  • если атрибут домена файла 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 etc.

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

81

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

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

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

ответ на добавлено:
  • будет печенье для .example.com будьте доступны для www.example.com?да
  • будет печенье для .example.com будьте доступны для example.com?не знаю
  • будет ли печенье для example.com будьте доступны для www.example.com?не должен, но...*
  • будет ли печенье для example.com будьте доступны для anotherexample.com?нет
  • будет www.example.com быть в состоянии установить cookie для example.com?да
  • будет www.example.com быть в состоянии установить cookie для www2.example.com?нет(кроме via .example.com)
  • будет www.example.com быть в состоянии установить cookie для. com?нет(не удается установить cookie так высоко в пространстве имен, и вы не можете установить его для чего-то вроде .ко.Великобритания).

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

6

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

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

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

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

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

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

4

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

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

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

3

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

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

2

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

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

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

будет печенье для .example.com будьте доступны для www.yyy.example.com-нет.

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

2

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

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

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

1