subdomain.example.com может установить cookie, который может быть считан example.com?
Другой вопрос состоит в том, являетесь ли Вы IO, связанным в сети FC, попросите, чтобы парни SAN продемонстрировали (графики хороши) фактическая запасная доступная пропускная способность (о, и если переключатели FC являются Cisco, как они удостоверяются, что избегают проблем пропускной способности в переключателе),
При заключении в кавычки из того же 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 находится в теории obsoleted RFC2965, который продиктовал вещи о принуждении ведущей точки для доменов на Set-Cookie2 операции.
Что более важно, как отмечено @Tony, реальный мир. Для взгляда на то, что делают фактические агенты пользователя, посмотрите
и
Для перспективы в то, что делают фактические сайты, попытайтесь играть с wget использование --save-cookies, --load-cookies, и --debug видеть, что продолжается.
Вы, вероятно, найдете, что на самом деле большинство сайтов использует некоторую комбинацию Set-Cookie от более старой спецификации RFC со значениями "Хоста", неявно без ведущей точки (поскольку twitter.com делает), или устанавливающий Значения домена (с ведущей точкой) и перенаправляющий к серверу как www.example.com (поскольку google.com делает).
Это не должно быть возможно. Однако как Вы сказали, так как это не широко зарегистрированный стандарт, он зависит от того, какую часть программного обеспечения Вы используете.
Большинство современных браузеров придерживается определенной "модели безопасности в Интернете". Модель эффективно управляет поведением браузеров относительно безопасности на вещах как cookie (конкретно, как их передадут обратно любому данному веб-сайту). Модель также имеет правило, что "браузеры не отправляют cookie в доменные имена, которые не установили их".
Однако domain.com должен смочь установить cookie для js.domain.com. js.domain.com, однако, может только установить cookie для себя. Но это - все в зависимости от того, какой браузер Вы используете.
Если браузер реализует RFC 6265 , что любой современный браузер должен делать в в этот момент в файле cookie, установленном для .example.com , будет игнорироваться начальная точка (раздел 5.2.3), и файл cookie будет отправлен в чистый домен и во все поддомены.
Не полагайтесь на это поведение, если у вас есть значительный трафик из старых браузеров; этот RFC датирован только 2011 годом.