Кратко

  • RFC 2965 октября 2000 года предложил согласование версий. Клиент, понимавший старые и новые cookies, должен был продолжать отправлять Cookie в подходящих случаях и добавлять Cookie2: $Version="1". Сервер с поддержкой новой версии должен был перейти на Set-Cookie2; старый мог проигнорировать объявление.
  • В новой серверной выдаче атрибут Port ограничивал порты, куда вернётся cookie, а CommentURL давал адрес объяснения для пользователя. Объявленная способность, ответ сервера и прочитанное человеком объяснение представляли разные этапы.
  • RFC 6265 апреля 2011 года заменил RFC 2965, потребовал перевести его в исторический статус и отказался от Cookie2 и Set-Cookie2. Он описал фактически используемые Cookie и Set-Cookie и указал, что cookies одного хоста остаются общими для его портов.

Браузер показывает карточку допуска

Интернет-магазину нужно помнить корзину между запросами HTTP. Сервер выдаёт браузеру значение состояния, а тот возвращает его в последующих подходящих запросах. RFC 2109 февраля 1997 года уже описывал раннюю форму этого обмена. Улучшить правила оказалось сложнее, чем их написать: сеть состояла из браузеров и серверов, выпущенных в разное время. Единого диспетчера, способного обновить все программы за один день, не было.

RFC 2965 октября 2000 года устроил переход как переговоры. Серверу дали новый заголовок ответа Set-Cookie2, клиенту — объявление о своих возможностях Cookie2. Если браузер понимал и новые правила, и прежние cookies, он продолжал возвращать старый Cookie для значения, полученного через Set-Cookie. Одновременно должен был послать Cookie2: $Version="1". Дополнительная строка говорила: со мной можно разговаривать и по-новому.

Если сервер тоже понимал новый порядок, он должен был продолжать с Set-Cookie2. Незнакомый с ним сервер просто игнорировал Cookie2, и прежний обмен сохранялся. Обновлённый клиент мог назвать свои возможности, не требуя от старого сервера немедленного переучивания.

Заголовки нельзя менять местами в описании этой истории. Cookie2 объявлял версию, которую понимал клиент, и не становился ёмкостью для всех значений сеанса. Set-Cookie2 был ответом сервера с новыми значениями и атрибутами. Применимые сохранённые значения затем возвращались в запросе Cookie. Найти в сетевой записи одну только карточку возможности — ещё не значит найти согласие сервера и последующее использование нового состояния.

В документе сервер мог начать и завершить обмен состоянием, а приложение могло решить, как употребить возвращённый cookie. Схема передачи данных между программами не подтверждала завершённую покупку или осведомлённое решение человека. Сначала нужно отделить способность к новому протоколу от выбранного ответа, а ответ — от результата работы сайта.

Зачем понадобился новый путь

У Set-Cookie2 были не только новые буквы. Атрибут Port позволял ограничить возврат значения. Если атрибута не было, cookie мог вернуться на любой порт соответствующего хоста. Если Port стоял без значения, возврат ограничивался портом первоначального запроса. Если перечислялись номера портов, допускались только они. Для нескольких служб на одной машине это был способ сузить круг получателей состояния.

CommentURL касался другой границы. Стандарт призывал сервер объяснять пользователю назначение cookies и предпочитал адрес страницы краткому комментарию: там помещалось больше информации и больше языков. Так можно было открыть дверь к осмысленному выбору. Указанный адрес ещё не свидетельствовал, что человек открыл страницу, прочитал её или одобрил конкретное действие.

Итак, новое поколение предлагало контроль портов, страницу объяснения и способ узнать, готова ли другая сторона пользоваться этими возможностями. Но каждый пункт требовал участия обоих концов соединения. Сервер с новым ответом не мог заставить старый браузер принять его. Браузер с новой карточкой не мог заставить старый сервер ответить по-новому.

Совместимости посвящены подробные правила. Старый пользовательский агент, не знавший Set-Cookie2, продолжал пользоваться прежними cookies. Агент, понимавший оба варианта, различал, через какой ответ получил значение, и выбирал соответствующий порядок возврата. Если сервер присылал для равнозначного cookie оба вида поля, новый имел приоритет у поддерживающего клиента. Старые сеансы сохранялись, но новое программное обеспечение получало две параллельные обязанности.

Эти RFC не подсчитывают, сколько браузеров отправили Cookie2 и сколько серверов отвечали Set-Cookie2. Для хронологии внедрения потребовались бы датированные выпуски программ и реальные трассы. Первичные документы надёжно фиксируют устройство предложения и его дальнейшую судьбу в стандартах.

В 2011 году главным стал действующий маршрут

RFC 6265 апреля 2011 года начал с фактического использования Cookie и Set-Cookie в Интернете. Во введении он сказал, что прежние описания, включая RFC 2109 и RFC 2965, не отражали его достаточно точно. Серверам рекомендовали более упорядоченную выдачу, клиентам предписали более терпеливую обработку существующих ответов ради совместимости. Сначала посмотрели на движение, затем написали правила дороги.

В том же введении авторы попросили перевести RFC 2109 и RFC 2965 в исторический статус, заменили RFC 2965 и явно отказались от Cookie2 и Set-Cookie2. В реестре заголовков оба новых названия обозначены как устаревшие. Объявление о возможности и специальный ответ были выведены из центрального договора; привычная пара полей осталась.

Документ 2011 года не утверждал, что привычная пара безупречна. Он прямо отмечал, что cookies одного хоста разделяются между разными портами, хотя браузерная политика происхождения обычно различает контент по портам. Port образца 2000 года как раз позволял выражать более узкую границу. Новый стандарт описал работающую практику, а не вернул атрибут из отменённой ветви в её центр.

Это столкновение не сводится к вкусу авторов заголовков. В 2000 году правила обходили несовместимость и оставляли старую дорогу открытой. Сервер решал, каким полем отвечать, клиент — объявлять ли способность, а старое программное обеспечение могло игнорировать неизвестное имя. Каждый участник владел своей частью перехода. Авторы стандарта могли согласовать их поведение на бумаге, но не включить новый код на каждом работающем устройстве.

Формальный итог ясен: RFC 2965 был заменён, оба versioned-поля отменены. Когда определённый браузер включил или выключил Cookie2, в этих документах не сказано; такую историю раскрыли бы датированные записи его разработки. Тексты 2000 и 2011 годов уже показывают разворот стандарта — от согласуемого нового языка к тому, на котором сеть фактически продолжала говорить.

Запасная дверь стала главным входом

План Cookie2 бережно обходился со старой сетью. Новый клиент предлагал способность, новый сервер мог её принять, старые программы продолжали привычную работу. Эта бережность спасала совместимость и позволяла каждому ждать, пока другая сторона сначала вложится в обновление. Выгода нового пути появлялась только при встрече двух готовых программ.

Последствия видны в исходных текстах. Port и CommentURL остались в ветви, которую документ 2011 года снял с основного маршрута. Реально применяемый обмен сохранял широкую область cookies между портами и другие ограничения, о которых новый RFC говорил открыто. Улучшение, написанное в стандарте, не меняет свойства сети без внедрения у её участников.

Временный обход может оказаться настолько удобным, что становится постоянным. Cookie2 приглашал на новую дорогу, а старую не перекрывал. Через одиннадцать лет стандарт убрал приглашение в архив и описал дорогу, по которой всё это время шли пользователи.