En commentaire de user2864740 26 septembre 16 à 16:44 - Le lien est mort, apparemment le domaine erik.io a été transmis à un autre utilisateur ou registraire de domaine.
qxotk
Réponses:
58
local.test.comsera utilisé pour le domaine, tandis que .local.test.comsera également utilisé pour les sous-domaines.
Cela local.test.comne s’appliquera donc pas à x.local.test.com, mais .local.test.coms’appliquera à la fois à local.test.comet à x.local.test.com?
ripper234
29
Je pense que c'est incorrect. Les cookies sont partagés avec tous les sous-domaines en aval, avec ou sans point. Vous pouvez considérer les sous-domaines comme «héritant» des cookies de leur parent. Ainsi, la définition d'un cookie sur example.com le définit sur blog.example.com et my.blog.example.com. La définition d'un cookie sur blog.example.com le définit sur this.is.my.blog.example.com et tous les sous-domaines intermédiaires. Mais, tout comme l'héritage, l'inverse n'est pas vrai. La définition d'un cookie sur blog.example.com ne le définit pas sur example.com.
geddski
6
Cela dit, vous POUVEZ limiter le cookie à l'hôte uniquement en ne définissant pas du tout le domaine du cookie (ou en définissant une chaîne vide). Cela, étrangement, définira le cookie uniquement pour l'hôte (example.com) et non pour aucun de ses sous-domaines.
geddski
8
Pour clarifier en fonction d'une autre réponse, le point faisait une différence, mais maintenant ce n'est pas le cas. Le cookie sera envoyé à n'importe quel sous-domaine du domaine spécifié, avec ou sans le premier point. Ce qui contrôle réellement la transmission aux sous-domaines, c'est si vous définissez ou non un domaine sur le cookie. Si vous ne définissez aucun domaine, le cookie ne sera envoyé qu'au domaine exact qui l'a émis. Il ne sera jamais envoyé à des domaines parents moins spécifiques (par exemple, "local.test.com" ne sera pas inclus dans les demandes adressées à "test.com"), et il ne sera envoyé aux sous-domaines correspondants que si vous définissez une valeur de domaine.
Triynko
4
@Triynko, le point fait une différence lorsque vous essayez de mettre à jour un cookie. Je n'ai pas réussi à isoler toutes les règles, mais j'ai vu les résultats varier en fonction de la présence du point de tête ou non, et ce n'est pas simple. Son fonctionnement varie selon le navigateur et n'est pas entièrement intuitif. Contrôler si un nom de cuisine a ou non un point de tête sur le navigateur n'est pas la tâche de programmation la plus simple que j'ai jamais faite.
DanAllen
83
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. )
La RFC est datée d'avril 2011. IE8 et IE9 ont été initialement publiés avant cette date et - malheureusement - sont toujours utilisés. Donc, ma meilleure supposition (je n'ai pas essayé) est qu'ils ont besoin du premier point. Est-ce que quelqu'un connaît une estimation du nombre de navigateurs dans la nature qui fonctionnent encore sur l'ancienne RFC?
BlaM
erik.io/blog/2014/03/04/definitive-guide-to-cookie-domains recommande d'utiliser un point en tête pour une meilleure compatibilité lorsque vous souhaitez inclure des sous-domaines. Cette exigence de compatibilité ne fera que diminuer. (Non requis pour 6255, mais requis et avec le même résultat final que pour 2109.)
Bien que les définitions soient quelque peu différentes, nous pouvons la simplifier pour l'une de ces implémentations comme suit :
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.
Autres observations intéressantes:
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.
Réponses:
local.test.comsera utilisé pour le domaine, tandis que.local.test.comsera également utilisé pour les sous-domaines.la source
local.test.comne s’appliquera donc pas àx.local.test.com, mais.local.test.coms’appliquera à la fois àlocal.test.comet à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.
RFC 6265 section 4.1.2.3
la source
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 :
la source
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.
la source