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:
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
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 ).