Я просто не могу поверить, что это так сложно определить.
Даже прочитав RFC, мне непонятно, может ли сервер subdomain.example.com устанавливать cookie, который может быть прочитан example.com.
subdomain.example.com может установить файл cookie, атрибут домена которого - .example.com. RFC 2965 явно заявляет, что такой файл cookie не будет отправлен на example.com, но в равной степени говорит, что если вы установите Domain = example.com, точка будет добавлена вперед, как если бы вы сказали .example.com. Все вместе это говорит о том, что если example.com возвращает файл cookie с Domain = example.com, он не возвращает этот файл cookie! Это не может быть правдой.
Кто-нибудь может прояснить, какие на самом деле правила?
Цитата из того же RFC2109 ты читаешь:
* A Set-Cookie from request-host x.foo.com for Domain=.foo.com would
be accepted.
Так subdomain.example.com может установить cookie для .example.com. Все идет нормально.
The following rules apply to choosing applicable cookie-values from
among all the cookies the user agent has.
Domain Selection
The origin server's fully-qualified host name must domain-match
the Domain attribute of the cookie
Так у нас есть совпадение домена?
* A is a FQDN string and has the form NB, where N is a non-empty name
string, B has the form .B', and B' is a FQDN string. (So, x.y.com
domain-matches .y.com but not y.com.)
Но сейчас example.com не соответствует домену .example.com по определению. Но www.example.com (или любое другое «непустое имя» в домене). Теоретически этот RFC устарел RFC2965, который продиктовал необходимость установки ведущей точки для доменов на Set-Cookie2 операции.
Как отмечает @Tony, более важным является реальный мир. Чтобы получить представление о том, что делают настоящие пользовательские агенты, см.
и
Чтобы понять, что делают реальные сайты, попробуйте поиграть с wget с помощью --save-cookies, --load-cookies, и --debug чтобы увидеть, что происходит.
Вы, вероятно, обнаружите, что на самом деле большинство сайтов используют комбинацию Set-Cookie из более старой спецификации RFC со значениями "Host", неявно без начальной точки (как twitter.com делает) или установка значений домена (с начальной точкой) и перенаправление на сервер, например www.example.com (так как google.com делает).
Если браузер реализует RFC 6265, который на данном этапе должен делать любой современный браузер, то для .example.com будет игнорироваться начальная точка (раздел 5.2.3), а затем cookie будет отправлен в голый домен и во все поддомены.
Не полагайтесь на это поведение, если у вас есть значительный трафик из старых браузеров; этот RFC датируется только 2011 годом.
Это не должно быть возможным. Однако, как вы сказали, поскольку это не широко документированный стандарт, это зависит от того, какое программное обеспечение вы используете.
Большинство современных браузеров придерживаются определенной «модели веб-безопасности». Модель эффективно управляет поведением браузеров в отношении безопасности таких вещей, как файлы cookie (в частности, как они будут отправляться обратно на любой данный веб-сайт). В модели также есть правило, согласно которому «браузеры не отправляют файлы cookie доменным именам, которые их не установили».
При этом domain.com должен иметь возможность устанавливать файлы cookie для js.domain.com. Однако js.domain.com может устанавливать файлы cookie только для себя. Но все зависит от того, какой браузер вы используете.