Wie werden mehrere Cookies mit demselben Namen behandelt?

Question

Sprich zum Beispiel hatte ich eine Anwendung die folgenden HTTP-Header zu senden, um Cookie zu setzen namens „a“:

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

Wenn ich /example auf dem Server zugreifen beide Pfade gültig sind, so habe ich zwei Namen Cookies „ein "! Da der Browser keine Pfadinformationen sendet, können die beiden Cookies nicht unterschieden werden.

Cookie: a=2; a=1 

Wie soll dieser Fall behandelt werden? Wählen Sie den ersten? Erstellen Sie eine Liste mit allen Cookie-Werten? Oder sollte ein solcher Fall als ein Fehler des Entwicklers betrachtet werden?

Answer 1

Von this article on SitePoint:

Wenn mehrere Cookies mit dem gleichen Namen eine bestimmte Anforderung URI übereinstimmen, vom Browser gewählt wird.

Je spezifischer der Pfad, desto höher der Vorrang. Der Vorrang, der auf anderen Attributen basiert, einschließlich der Domäne, ist jedoch nicht angegeben und kann zwischen den Browsern variieren. Das heißt, wenn Sie Cookies mit dem gleichen Namen gegen ".example.org" und "www.example.org" gesetzt haben, können Sie nicht sicher sein, welche Datei zurückgesendet wird.

Edit: diese Information von 2010 erscheint überholt zu sein, wie es scheint Browser jetzt mehr Cookies im Gegenzug siehe Antwort von @Nate unten für Details

Answer 2

Wenn Sie sie unterscheiden müssen, müssen Sie ihnen verschiedene Schlüsselwerte geben.

Answer 3

Ich bin mir sicherlich der Anwendungen bewusst, die dies weitgehend mit mehreren Session-IDs tun - und scheinen konsistent zu arbeiten. Ich weiß es jedoch nicht - und habe nicht die Absicht, es herauszufinden -, weil der Browser die Cookies in einer konsistenten Reihenfolge zurückgibt, je nachdem wann sie eingestellt wurden/für welchen Pfad sie festgelegt wurden oder ob die App versucht, sie zu finden Eins zu einer bestehenden Sitzung.

Ich würde dringend empfehlen, diese Praxis zu vermeiden.

Wenn Sie jedoch wirklich wissen möchten, wie die Browser (und Apps) mit diesem Szenario umgehen, sollten Sie einen Test-Rig bauen und es ausprobieren.

Answer 4

Es ist nichts falsch mit mit mehreren Werten für die schicken gleicher Name ... wenn du sie willst. Sie könnten sogar zusätzlichen Kontext in den Wert einbetten.

Wenn nicht, dann sind natürlich verschiedene Namen eine Lösung, wenn Sie beide Kontexte wollen.

Die Alternative besteht darin, denselben Cookie-Namen mit dem gleichen Pfad (und der gleichen Domäne) auch aus den spezifischeren Pfaden zu senden. Diese Cookie-Anweisungen überschreiben den Wert dieses Cookies.

Jetzt, da Sie den wichtigsten Teil (wie sie funktionieren) kennen, und dass Sie erreichen können, was Sie auf ein paar verschiedene Arten brauchen, ist meine Antwort auf Ihre Frage: Dies ist ein Entwicklerproblem.

Answer 5

Die Antwort zu einem Artikel auf SitePoint ist nicht vollständig. Bitte beachten Sie RFC 6265 (um fair zu sein, wurde diese RFC im Jahr 2011 veröffentlicht, nachdem diese Frage veröffentlicht wurde, die vorherige RFC 2965 von 2000 und RFC 2109 von 1997 ersetzt).

Abschnitt 5.4, Absatz 2 hat folgende zu sagen:

• Plätzchen mit längeren Pfaden aufgelistet mit kürzeren Wegen, bevor Cookies:

  Der User-Agent der Cookie-Liste in der folgenden Reihenfolge sortieren soll.

HINWEIS: Nicht alle sortieren User Agents die Cookie-Liste in dieser Reihenfolge, aber diese Reihenfolge spiegelt gängige Praxis, wenn dieses Dokument geschrieben wurde, und, historisch gibt es Server, die (fälschlicherweise) hingen von diese Bestellung.

Es gibt auch dieses kleine Juwel in Abschnitt 4.2.2:

... Server, sollten Sie nicht auf die Serialisierungsordnung verlassen. In insbesondere, wenn der Cookie-Header zwei Cookies mit dem gleichen Namen enthält (z. B. die mit anderen Pfad- oder Domänenattributen festgelegt wurden), SOLLTEN sich Server NICHT auf die Reihenfolge verlassen, in der diese Cookies im Header erscheinen.

In Ihrem Beispiel Anfrage Cookie (Cookies: a = 2, a = 1) beachten, dass das Cookie mit dem Beispiel /Pfad gesetzt (a = 2) hat einen längeren Weg als der, mit dem Pfad / (a = 1) und so wird es zuerst an Sie zurückgeschickt, was der Empfehlung der Spezifikation entspricht. Somit sind Sie mehr oder weniger korrekt in der Annahme, dass Sie den ersten Wert auswählen können.

Leider ist die Sprache in RFCs verwendet wird, ist sehr spezifisch - die Verwendung der Worte SOLL und sollten Sie nicht Mehrdeutigkeit in RFCs einzuführen. Diese geben Konventionen an, die sollten befolgt werden, sind aber nicht erforderlich, um die Spezifikation zu entsprechen. Während ich den RFC dafür ziemlich gut verstehe, habe ich die Forschung nicht gemacht, um zu sehen, was reale Kunden tun; Es ist möglich, dass ein oder mehrere Browser oder andere Software, die als HTTP-Clients fungieren, das längste Pfad-Cookie (/Beispiel) nicht zuerst im Cookie: Header senden.

Wenn Sie in der Lage sind, den Wert des Cookies zu steuern, und Sie mögen Ihre Lösung narrensicher machen, sind Sie am besten aus entweder:

1. einen anderen Cookie-Namen unter Verwendung von in bestimmten Pfaden außer Kraft zu setzen, wie zum Beispiel:

   • Set-Cookie: a-global = 1; path = /; Version = 1
   • Set-Cookie: a-Beispiel = 2; Path =/example, Version = 1

2. Speichern der Pfad, den Sie in der Cookie-Wert müssen selbst:

   • Set-Cookie: a = 1 & path = /; path = /; Version = 1
   • Set-Cookie: a = 2 & path =/example; Path =/example, Version = 1

beiden Abhilfen erfordern zusätzliche Logik auf dem Server den gewünschten Cookie-Wert zu wählen, indem die angeforderte URL gegen die Liste der verfügbaren Cookies zu vergleichen . Es ist nicht zu schön. Es ist bedauerlich, dass der RFC nicht vorausschauend voraussetzte, dass ein längerer Pfad ein Cookie mit einem kürzeren Pfad vollständig überschreibt (zB: in Ihrem Beispiel würden Sie Cookie erhalten: a = 2nur).