В чем разница между local.test.com
и .local.test.com
? Снимок экрана сделан из Chrome.
В чем разница между local.test.com
и .local.test.com
? Снимок экрана сделан из Chrome.
local.test.com
будет использоваться для домена, а .local.test.com
также будет использоваться для поддоменов.
Ведущая точка означает, что файл cookie действителен и для поддоменов; Тем не менее последние спецификации HTTP (RFC 6265) изменили это правило, поэтому современные браузеры не должны заботиться о ведущей точке. Точка может понадобиться для старого браузера, использующего устаревший RFC 2109.
Например, если значение атрибута Domain является "example.com", пользовательский агент будет включать куки файл в заголовок Cookie при выполнении HTTP-запросов на example.com, www.example.com и www.corp.example.com. (Обратите внимание, что ведущий% x2E ( "." ), Если он присутствует, игнорируется, хотя этот символ недопустим, но конечный% x2E ( "." ), Если он присутствует, заставит агент пользователя игнорировать атрибут. )
Из статьи Окончательное руководство по доменам cookie и почему www-префикс делает ваш сайт более безопасным:
Заключение
Хотя определения несколько отличаются, мы можем его упростить для любой из этих реализаций как:
Другие заслуживающие внимания наблюдения:
Если в cookie не задан домен, cookie должен соответствовать только точное имя хоста запроса. [ПРИМЕЧАНИЕ: это отличается от возврата Set-Cookie с доменом без точки!] Нет поддоменов, нет частичных совпадений. Это означает, что просто не включать атрибут домена - он недействителен для установки пустого атрибута домена. К сожалению, Internet Explorer похоже, рассматривает это как имя хоста вместе с любыми подобластями.
При настройке домена в cookie безопасный выбор заключается в том, чтобы он предшествовал точкой, как .erik.io. Файл cookie будет соответствовать всем поддоменам.
Настройка домена cookie без предшествующей точки, например erik.io, недействителен в реализациях RFC 2109, и будет как с предыдущей точкой на других реализациях. Там есть никоим образом не ограничивать куки файл конкретным явно заданным доменом, без включенных поддоменов.
Во всех RFC указанный домен cookie должен соответствовать текущему хосту имя, для нормального соответствия. Настройка файла cookie для www.erik.io в ответ от erik.io недействителен, поскольку cookie с доменом www.erik.io не соответствует erik.io, первый из них более конкретный.
В RFC 6265 домены явно сбрасываются при анализе Заголовок Set-Cookie.
Ведущей точкой в ".local.test.com" является то, как хром просматривает файлы cookie с параметром "Domain = local.test.com" (или "Domain =.local.test.com", который является то же самое).
Определения Set-Cookie без "Domain = something" просматривает домен (= хост) без ведущей точки.
Таким образом, ведущая точка в хроме не отражает, использовалась ли ведущая точка с сервера, но имеет ли этот файл cookie "Domain = something" в своем определении с сервера. (И если бы это было так, файл cookie также будет отправлен в поддомены).
По крайней мере, это показывают мои тесты. Хром должен сделать это проще для чтения, например, просмотреть точную строку, которая определила файл cookie и когда он был получен.