Как обрабатывать несколько файлов cookie с одним и тем же именем?

Question

Скажем, например, у меня было приложение, отправляющее следующие HTTP-заголовки для установки в cookie с именем «a»:

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

Если я получаю доступ к /example на сервере, оба пути действительны, поэтому я имеюдва печенья с именем "а"!Поскольку браузер не отправляет информацию о пути, два файла cookie невозможно различить.

Cookie: a=2; a=1

Как следует обращаться с этим делом?Выбрать первый?Создать список со всеми значениями cookie?Или такой случай следует рассматривать как ошибку разработчика?

Answer 1

Ответ, относящийся к статье на SitePoint, не является полностью полным. См. RFC 6265 (если честно, этот RFC был выпущен в 2011 году после публикации этого вопроса, который заменяет предыдущие RFC 2965 от 2000 года и RFC 2109 от 1997).

Раздел 5.4, подраздел 2 имеет следующее:

Пользовательский агент ДОЛЖЕН сортировать список файлов cookie в следующем порядке:

• Файлы cookie с более длинными путями перечислены перед файлами cookie с более короткими путями.

ПРИМЕЧАНИЕ. Не все пользовательские агенты сортируют список файлов cookie в этом порядке, но это порядок отражает обычную практику, когда этот документ был написан, и, исторически существовали серверы, которые (ошибочно) зависели от этот заказ.

В разделе 4.2.2 также есть этот маленький драгоценный камень:

... серверам НЕ СЛЕДУЕТ полагаться на порядок сериализации. В в частности, если заголовок Cookie содержит два файла cookie с одинаковыми имя (например, которые были установлены с различными атрибутами пути или домена), серверы НЕ ДОЛЖНЫ полагаться на порядок, в котором эти куки появляются в заголовке.

В вашем примере файла cookie запроса ( Cookie: a = 2; a = 1 ) обратите внимание, что файл cookie установлен с путем / example ( a = 2 * 1032) *) имеет более длинный путь, чем путь с / ( a = 1 ), и поэтому он отправляется обратно вам первым в строке, что соответствует рекомендации спецификации. Таким образом, вы более или менее правы в своем предположении, что вы могли бы выбрать первое значение.

К сожалению, язык, используемый в RFC, чрезвычайно специфичен - использование слов ДОЛЖНО и НЕ ДОЛЖНО вносить двусмысленность в RFC. Они указывают на соглашения, согласно которым следует , но не требуется , чтобы соответствовать спецификации. Хотя я достаточно хорошо понимаю RFC, я не провел исследования, чтобы увидеть, что делают клиенты в реальном мире; Возможно, что один или несколько браузеров или других программ, действующих как клиенты HTTP, могут не отправлять файл cookie с самым длинным путем (например: / example ) первым в заголовке Cookie: .

Если вы в состоянии контролировать значение файла cookie и хотите, чтобы ваше решение было надежным, лучше всего:

1. использование другого имени файла cookie для переопределения в определенных путях, например:

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

2. сохранение нужного вам пути в самом значении cookie:

   • Set-cookie: a = 1 & path = /; Path = /; Version = 1
   • Set-cookie: a = 2 & path = / example; Path = / example; версия = 1

Оба эти обходных пути требуют дополнительной логики на сервере, чтобы выбрать желаемое значение cookie, сравнивая запрошенный URL-адрес со списком доступных cookie-файлов. Это не слишком красиво. К сожалению, у RFC не было предвидения требовать, чтобы более длинный путь полностью заменял cookie-файл с более коротким путем (например: в вашем примере вы получите Cookie: a = 2 только ).

Answer 2

С этой статьи на SitePoint :

Если несколько файлов cookie с одинаковым именем соответствуют заданному URI запроса, браузер выбирает один из них.

Чем конкретнее путь, тем выше приоритет.Однако приоритет, основанный на других атрибутах, включая домен, не определен и может варьироваться в зависимости от браузера.Это означает, что если вы установили файлы cookie с тем же именем для «.example.org» и «www.example.org», вы не можете быть уверены, какой из них будет отправлен обратно.

Изменить: эта информация за 2010 год выглядит устаревшей, похоже, что браузеры теперь могут отправлять взамен несколько куки, подробности см. В ответе @Nate ниже

Answer 3

Нет ничего плохого в том, чтобы иметь несколько значений для одного и того же имени ... если вы хотите их. Вы можете даже вставить дополнительный контекст в значение.

Если вы этого не сделаете, то, конечно, разные имена - это решение, если вы хотите оба контекста.

Альтернативой является отправка того же имени файла cookie с тем же путем (и доменом) даже из более конкретных путей. Эти установленные инструкции cookie перезапишут значение этого cookie.

Теперь, когда вы знаете самую важную часть (как они работают) и что вы можете выполнить то, что вам нужно, несколькими различными способами, я отвечу на ваш вопрос: это проблема разработчика.

Answer 4

Я, конечно, знаю о приложениях, которые делают это интенсивно, используя несколько идентификаторов сеансов - и, кажется, работают согласованно.Однако я не знаю - и не собираюсь выяснять - будут ли они делать это, потому что браузер возвращает файлы cookie в согласованном порядке, в зависимости от того, когда они были установлены / для какого пути они были установлены, или от того, пытается ли приложение соответствовать каждому из них.один к существующему сеансу.

Я настоятельно рекомендую избегать этой практики.

Однако, если вы действительно хотите знать, как браузеры (и приложения) обрабатывают этот сценарий, почему бы не создатьиспытательный стенд и опробуйте его.

Answer 5

Если вам нужно различить их, вы должны дать им различные значения ключа.