Citant le même RFC2109 que vous lisez:
* Un Set-Cookie de l'hôte de requête x.foo.com pour Domain = .foo.com serait
être accepté.
Vous subdomain.example.com
pouvez donc définir un cookie pour .example.com
. Jusqu'ici tout va bien.
Les règles suivantes s'appliquent au choix des valeurs de cookie applicables dans
parmi tous les cookies de l'agent utilisateur.
Sélection de domaine
Le nom d'hôte complet du serveur d'origine doit correspondre au domaine
l'attribut Domain du cookie
Avons-nous donc une correspondance de domaine?
* A est une chaîne FQDN et a la forme NB, où N est un nom non vide
chaîne, B a la forme .B 'et B' est une chaîne FQDN. (Alors, xycom
correspond au domaine .y.com mais pas y.com.)
Mais maintenant example.com
, le domaine ne correspondrait pas .example.com
à la définition. Mais www.example.com
(ou tout autre "nom non vide" dans le domaine) le ferait. Cette RFC est en théorie obsolète par la RFC2965 , qui dictait les choses sur le forçage d'un point de tête pour les domaines sur les Set-Cookie2
opérations.
Plus important, comme l'a noté @Tony, c'est le monde réel. Pour un aperçu de ce que font réellement les agents utilisateurs, consultez
Firefox 3 de nsCookieService.cpp
et
Cookie_monster.cc de Chrome
Pour la perspective dans ce que les sites réels font, essayer de jouer avec l' wget
aide --save-cookies
, --load-cookies
et --debug
de voir ce qui se passe.
Vous constaterez probablement qu'en fait la plupart des sites utilisent une combinaison de Set-Cookie
l'ancienne spécification RFC avec des valeurs "Host", implicitement sans point de tête (comme twitter.com ) ou définissent des valeurs de domaine (avec un point de tête) et redirigent à un serveur comme www.example.com
(comme google.com ).