Quelle est la différence entre local.test.com
et .local.test.com
? La capture d'écran provient de Chrome.
Quelle est la différence entre local.test.com
et .local.test.com
? La capture d'écran provient de Chrome.
Réponses:
local.test.com
sera utilisé pour le domaine, tandis que .local.test.com
sera également utilisé pour les sous-domaines.
local.test.com
ne s’appliquera donc pas à x.local.test.com
, mais .local.test.com
s’appliquera à la fois à local.test.com
et à x.local.test.com
?
Le point de tête signifie que le cookie est également valide pour les sous-domaines; néanmoins, des spécifications HTTP récentes (RFC 6265) ont changé cette règle, de sorte que les navigateurs modernes ne devraient pas se soucier du point de tête. Le point peut être nécessaire par l'ancien navigateur implémentant la RFC 2109 obsolète.
Par exemple, si la valeur de l'attribut Domaine est "exemple.com", l'agent utilisateur inclura le cookie dans l'en-tête Cookie lors des requêtes HTTP à example.com, www.example.com et www.corp.example. com. (Notez qu'un% x2E (".") De début, s'il est présent, est ignoré même si ce caractère n'est pas autorisé, mais un% x2E (".") De fin, s'il est présent, amènera l'agent utilisateur à ignorer l'attribut. )
Extrait de l'article Le guide définitif des domaines de cookies et pourquoi un préfixe www rend votre site Web plus sûr :
Conclusion
Bien que les définitions soient quelque peu différentes, nous pouvons la simplifier pour l'une de ces implémentations comme suit :
Autres observations intéressantes:
Lorsqu'aucun domaine n'est défini dans le cookie, le cookie ne doit correspondre qu'au nom d'hôte exact de la demande. [REMARQUE: ceci est différent de renvoyer un Set-Cookie avec un domaine sans point!] Pas de sous-domaines, pas de correspondances partielles. Cela signifie simplement ne pas inclure l'attribut de domaine - il n'est pas valide de définir un attribut de domaine vide. Malheureusement, Internet Explorer semble traiter cela comme le nom d'hôte avec tous les sous-domaines .
Lors de la définition d'un domaine dans le cookie, le choix le plus sûr est de le faire précéder d'un point, comme .erik.io. Le cookie correspondra à tous les sous-domaines.
La définition d'un domaine de cookie sans point précédent, comme erik.io, n'est pas valide dans les implémentations RFC 2109, et produira le même comportement qu'avec un point précédent sur d'autres implémentations. Il n'existe aucun moyen de restreindre un cookie à un domaine défini explicitement spécifique, sans que les sous-domaines ne soient inclus.
Dans tous les RFC, un domaine de cookie spécifié doit correspondre au nom d'hôte actuel, par correspondance normale. La définition d'un cookie pour www.erik.io dans une réponse d'erik.io n'est pas valide, car un cookie avec le domaine www.erik.io ne correspond pas à erik.io, le premier étant plus spécifique.
Dans la RFC 6265, les domaines sont explicitement minuscules lors de l'analyse de l'en-tête Set-Cookie.
Le premier point dans ".local.test.com" est la façon dont Chrome voit les cookies avec un ensemble "Domain = local.test.com" (ou un "Domain = .local.test.com", qui est le même).
Les définitions Set-Cookie sans "Domaine = quelque chose" affiche le domaine (= hôte) sans point de début.
Ainsi, le point de tête dans chrome ne reflète pas si un point de début a été utilisé ou non à partir du serveur, mais si ce cookie a ou non un "Domaine = quelque chose" dans sa définition du serveur. (Et si tel était le cas, le cookie sera également envoyé aux sous-domaines).
Au moins, c'est ce que mes tests montrent. Chrome devrait faciliter la lecture, par exemple afficher la chaîne exacte qui a défini le cookie et quand il a été reçu.