Jak obsługiwać wiele plików cookie o tej samej nazwie?

Załóżmy na przykład, że miałem aplikację wysyłającą następujące nagłówki HTTP, aby ustawić plik cookie o nazwie „a”:

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

Jeśli mam dostęp /examplena serwerze, obie ścieżki są prawidłowe, więc mam dwa pliki cookie o nazwie „a”! Ponieważ przeglądarka nie wysyła żadnych informacji o ścieżce, nie można rozróżnić tych dwóch plików cookie.

Cookie: a=2; a=1

Jak należy postąpić w tej sprawie? Wybierz pierwszy? Utworzyć listę ze wszystkimi wartościami plików cookie? A może taki przypadek należy uznać za błąd dewelopera?

Z tego artykułu w witrynie SitePoint :

Jeśli do danego identyfikatora URI żądania pasuje wiele plików cookie o tej samej nazwie, przeglądarka wybiera jeden z nich.

Im bardziej szczegółowa ścieżka, tym wyższy priorytet. Jednak pierwszeństwo oparte na innych atrybutach, w tym domenie, jest nieokreślone i może się różnić w zależności od przeglądarki. Oznacza to, że jeśli ustawiłeś pliki cookie o tej samej nazwie na „.example.org” i „www.example.org”, nie możesz być pewien, który z nich zostanie odesłany.

Edycja: te informacje z 2010 roku wydają się być nieaktualne, wygląda na to, że przeglądarki mogą teraz wysyłać w zamian wiele plików cookie. Szczegółowe informacje można znaleźć w odpowiedzi od @Nate poniżej

Odpowiedź odnosząca się do artykułu w witrynie SitePoint nie jest pełna. Proszę zapoznać się z RFC 6265 (aby być uczciwym, ten dokument RFC został wydany w 2011 roku po opublikowaniu tego pytania, który zastępuje poprzednie RFC 2965 z 2000 roku i RFC 2109 z 1997 roku).

Sekcja 5.4 , podsekcja 2 ma do powiedzenia:

Klient użytkownika POWINIEN sortować listę plików cookie w następującej kolejności:

• Pliki cookie z dłuższymi ścieżkami są wymienione przed plikami cookie z krótszymi ścieżkami.

UWAGA: Nie wszystkie programy klienckie sortują listę plików cookie w tej kolejności, ale ta kolejność odzwierciedla powszechną praktykę w czasie tworzenia tego dokumentu, a historycznie istniały serwery, które (błędnie) zależały od tej kolejności.

W sekcji 4.2.2 znajduje się również ten mały klejnot :

... serwery NIE POWINNY polegać na kolejności serializacji. W szczególności, jeśli nagłówek Cookie zawiera dwa pliki cookie o tej samej nazwie (np. Które zostały ustawione z różnymi atrybutami ścieżki lub domeny), serwery NIE POWINNY polegać na kolejności, w jakiej te pliki cookie pojawiają się w nagłówku.

W Twoim przykładzie cookie żądania ( Cookie: a = 2; a = 1 ) zwróć uwagę, że plik cookie ustawiony ze ścieżką / przykład ( a = 2 ) ma dłuższą ścieżkę niż ten ze ścieżką / ( a = 1 ), więc jest odesłany do Ciebie jako pierwszy w kolejce, co odpowiada zaleceniu specyfikacji. W ten sposób są mniej lub bardziej poprawne w założeniu, że mógłby wybrać pierwszą wartość.

Niestety język używany w dokumentach RFC jest niezwykle specyficzny - użycie słów POWINNO i NIE POWINNO wprowadzać niejednoznaczności w dokumentach RFC. Wskazują one konwencje, których należy przestrzegać, ale nie jest wymagane, aby były zgodne ze specyfikacją. Chociaż całkiem dobrze rozumiem RFC w tym zakresie, nie przeprowadziłem badań, aby zobaczyć, co robią klienci w świecie rzeczywistym; Możliwe jest, że jedna lub więcej przeglądarek lub inne oprogramowanie działające jako klienci HTTP mogą nie wysyłać pliku cookie o najdłuższej ścieżce (np.: / example ) jako pierwszego w nagłówku Cookie : .

Jeśli jesteś w stanie kontrolować wartość pliku cookie i chcesz, aby Twoje rozwiązanie było niezawodne, najlepiej jest:

1. używanie innej nazwy pliku cookie do zastąpienia w niektórych ścieżkach, takich jak:

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

2. przechowywanie potrzebnej ścieżki w samej wartości pliku cookie:

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

Oba te obejścia wymagają dodatkowej logiki na serwerze w celu wybrania żądanej wartości pliku cookie poprzez porównanie żądanego adresu URL z listą dostępnych plików cookie. To nie jest zbyt ładne. To niefortunne RFC nie miał foresight wymagać, aby dłuższa droga całkowicie zastępuje cookie z krótszą ścieżkę (np: w przykładzie, byś otrzymywać Cookie: a = 2 tylko ).

Nie ma nic złego w posiadaniu wielu wartości dla tej samej nazwy ... jeśli ich potrzebujesz. Możesz nawet osadzić dodatkowy kontekst w wartości.

Jeśli tego nie zrobisz, oczywiście różne nazwy są rozwiązaniem, jeśli chcesz mieć oba konteksty.

Alternatywą jest wysłanie tej samej nazwy pliku cookie z tą samą ścieżką (i domeną) nawet z bardziej szczegółowych ścieżek. Te ustawione instrukcje dotyczące plików cookie nadpiszą wartość tego pliku cookie.

Teraz, gdy wiesz już najważniejszą część (jak one działają) i że możesz osiągnąć to, czego potrzebujesz na kilka różnych sposobów, moja odpowiedź na Twoje pytanie brzmi: to jest problem programisty.

Z pewnością jestem świadomy aplikacji, które robią to intensywnie przy użyciu identyfikatorów wielu sesji - i wydają się działać konsekwentnie. Jednak nie wiem - i nie mam zamiaru się dowiedzieć - czy tak robią, ponieważ przeglądarka zwraca pliki cookie w stałej kolejności w zależności od tego, kiedy zostały ustawione / dla której ścieżki zostały ustawione lub czy aplikacja próbuje dopasować je do każdego z nich jeden do istniejącej sesji.

Zdecydowanie zalecałbym unikanie tej praktyki.

Jeśli jednak naprawdę chcesz wiedzieć, jak przeglądarki (i aplikacje) radzą sobie z tym scenariuszem, może zbuduj platformę testową i wypróbuj ją.

Jeśli korzystasz ze środowiska Java / Scala Play: uważaj! Jeśli żądanie zawiera wiele plików cookie o tej samej nazwie, Play przedstawi tylko 1 z nich w Twoim kodzie.

Jeśli chcesz je rozróżnić, musisz nadać im różne kluczowe wartości.