Comment gérer plusieurs cookies portant le même nom ?

Question

Disons par exemple que j'ai une application qui envoie les en-têtes HTTP suivants pour définir un cookie nommé "a" :

Set-Cookie: a=1;Path=/;Version=1
Set-Cookie: a=2;Path=/example;Version=1

Si j'accède /example sur le serveur, les deux chemins sont valides, j'ai donc deux cookies nommés "a" ! Comme le navigateur n'envoie pas d'informations sur le chemin, les deux cookies ne peuvent pas être distingués.

Cookie: a=2; a=1

Comment traiter cette affaire ? Choisir le premier ? Créer une liste avec toutes les valeurs des cookies ? Ou ce cas doit-il être considéré comme une erreur du développeur ?

Answer 1

La réponse qui fait référence à un article sur SitePoint n'est pas tout à fait complète. Veuillez consulter RFC 6265 (pour être juste, cette RFC a été publiée en 2011 après que cette question ait été postée, ce qui remplace les précédentes RFC 2965 de 2000 et RFC 2109 à partir de 1997).

Section 5.4 le paragraphe 2 est ainsi libellé :

L'agent utilisateur DEVRAIT trier la liste des cookies dans l'ordre suivant :

• Les cookies dont le parcours est plus long sont énumérés avant les cookies dont le parcours est plus court.

NOTE : Tous les agents utilisateurs ne trient pas la liste des cookies dans cet ordre, mais cet ordre reflète la pratique courante au moment de la rédaction de ce document. mais cet ordre reflète la pratique courante lorsque ce document a été écrit, et, historiquement, il y a eu des serveurs qui dépendaient (à tort) de cet ordre. cet ordre.

Il y a aussi ce petit bijou dans la section 4.2.2 :

... les serveurs NE DOIVENT PAS se fier à l'ordre de sérialisation. Sur En particulier, si l'en-tête Cookie contient deux cookies portant le même nom nom (par exemple, qui ont été définis avec des attributs Path ou Domain différents), les serveurs NE DOIVENT PAS se fier à l'ordre dans lequel ces cookies apparaissent dans l'en-tête.

Dans votre exemple, le cookie de demande ( Cookie : a=2 ; a=1 ), notez que le cookie défini avec le chemin /exemple ( a=2 ) a un chemin plus long que celui de la trajectoire / ( a=1 ) et il vous est donc renvoyé en premier, ce qui correspond à la recommandation de la spécification. Ainsi, vous avez plus ou moins raison de supposer que vous pourrait sélectionner la première valeur.

Malheureusement, le langage utilisé dans les RFC est extrêmement spécifique - l'utilisation des mots DEVRAIT y NE DEVRAIT PAS introduisent des ambiguïtés dans les RFC. Ceux-ci indiquent les conventions qui debe à suivre, mais ne sont pas requis pour être conforme à la spécification. Bien que je comprenne très bien la RFC à ce sujet, je n'ai pas fait de recherches pour voir ce que font les clients du monde réel ; il est possible qu'un ou plusieurs navigateurs ou autres logiciels agissant en tant que clients HTTP n'envoient pas le cookie du chemin le plus long (ex : /exemple ) premier dans la Cookie : en-tête.

Si vous êtes en mesure de contrôler la valeur du cookie et que vous voulez que votre solution soit infaillible, il est préférable de choisir l'une des deux solutions suivantes :

1. utiliser un nom de cookie différent pour passer outre dans certains chemins, par exemple :

• Set-cookie : a-global=1;Path=/;Version=1
• Set-cookie : a-example=2;Path=/example;Version=1

2. en stockant le chemin dont vous avez besoin dans la valeur du cookie elle-même :

• Set-cookie : a=1&path=/;Path=/;Version=1
• Set-cookie : a=2&path=/exemple;Path=/exemple;Version=1

Ces deux solutions de contournement nécessitent une logique supplémentaire sur le serveur pour choisir la valeur de cookie souhaitée, en comparant l'URL demandée à la liste des cookies disponibles. Ce n'est pas très joli. Il est regrettable que la RFC n'ait pas eu la clairvoyance d'exiger qu'un chemin plus long remplace complètement un cookie avec un chemin plus court (par exemple, dans votre exemple, vous recevriez Cookie : a=2 uniquement ).

Answer 2

De cet article sur SitePoint :

Si plusieurs cookies du même nom correspondent à une demande URI donnée, le navigateur en choisit un.

Plus le chemin est spécifique, plus la préséance est élevée. Cependant, la préséance basée sur d'autres attributs, y compris le domaine, n'est pas spécifiée et peut varier selon les navigateurs. Cela signifie que si vous avez défini des cookies du même nom pour ".example.org" et "www.example.org", vous ne pouvez pas être sûr de celui qui sera renvoyé.

Edit : cette information de 2010 semble être dépassée, il semble que les navigateurs peuvent maintenant envoyer plusieurs cookies en retour, voir la réponse de @Nate ci-dessous pour plus de détails.

Answer 3

Il n'y a rien de mal à avoir plusieurs valeurs pour le même nom... si vous le souhaitez. Vous pouvez même intégrer un contexte supplémentaire dans la valeur.

Si ce n'est pas le cas, des noms différents sont bien sûr une solution si vous voulez les deux contextes.

L'alternative est d'envoyer le même nom de cookie avec le même chemin (et domaine) même à partir des chemins plus spécifiques. Ces instructions de configuration du cookie écraseront la valeur de ce cookie.

Maintenant que vous connaissez la partie la plus importante (comment ils fonctionnent), et que vous pouvez accomplir ce dont vous avez besoin de plusieurs manières différentes, ma réponse à votre question est la suivante : il s'agit d'un problème de développeur.

Answer 4

J'ai connaissance d'applications qui font cela de manière extensive en utilisant plusieurs identifiants de session - et qui semblent fonctionner de manière cohérente. Cependant, je ne sais pas - et je n'ai pas l'intention de le découvrir - s'ils le font parce que le navigateur renvoie les cookies dans un ordre cohérent en fonction du moment où ils ont été créés / du chemin pour lequel ils ont été créés ou si l'application essaie de faire correspondre chacun d'eux à une session existante.

Je recommande vivement d'éviter cette pratique.

Cependant, si vous voulez vraiment savoir comment les navigateurs (et les applications) gèrent ce scénario, pourquoi ne pas construire un banc d'essai et le tester.

Answer 5

Si vous devez les distinguer, vous devez leur donner des valeurs clés différentes.