Кратко

  • В 1994 году marketplaceMCI требовал сохранять сведения о заказах, оплате и доставке между веб-запросами. MCI отвергла первоначальный вариант Netscape с хранением состояния на сервере и потребовала оставить его у клиента.
  • Netscape превратила требование заказчика в общую функцию браузера: сервер отправлял значение состояния, а браузер возвращал его в последующих запросах в пределах заданной области. Само значение не доказывало, кто именно пользуется браузером.
  • В 1997 году RFC 2109 попытался стандартизировать механизм, который уже сформировали код и требования совместимости. Документ признавал ограничения контроля пользователя, читаемость значений и отсутствие защиты при передаче.

Корзина превратила забывчивость протокола в задачу для продукта

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

MCI разрабатывала marketplaceMCI — торговую площадку с фирменным браузером, веб-сервером, серверами продавцов для приёма и исполнения заказов, а также внутренними системами поддержки и учёта торговых аккаунтов. Задача была прикладной: связать информацию о заказе, оплате и доставке в цепочке запросов.

Ключевой выбор описан в более позднем судебном документе, а не в легенде об одиноком изобретателе. На встрече 10 августа 1994 года MCI отказалась от первоначального предложения Netscape хранить состояние на сервере. Информация должна была храниться на компьютере клиента. Суд указал, что это общее требование стороны не оспаривали, хотя по отдельным техническим подробностям они расходились.

Так изменилось место, где приложение хранило краткосрочную память. Между обращениями к серверу небольшой объект состояния должен был оставаться в браузере. Задачу поручили программисту Netscape Lou Montulli. Позже он вспоминал, что летом получил задание придумать корзину покупок для HTTP без постоянной сессии, но не помнил, что конкретным заказчиком была MCI. Marc Andreessen свидетельствовал, что проект MCI в итоге привёл к Cookie и что Netscape превратила решение в общую функцию. Эти показания связывают запрос клиента с продуктовым решением, но не устраняют неопределённость в деталях разработки.

Браузер стал переносчиком состояния приложения

В сохранившейся спецификации Netscape механизм описан просто. Сервер мог приложить объект состояния к HTTP-ответу. Браузер сохранял его, а затем включал в последующие запросы, URL которых попадал в область действия Cookie. Приложение на сервере выбирало значение и определяло его смысл; браузер хранил и возвращал это значение.

Так между запросами можно было переносить ссылку на корзину, регистрационные данные или настройки. HTTP от этого не стал протоколом с постоянным соединением. Кроме того, каждой странице не требовалось содержать персональную корзину каждого посетителя — это было важно для веб-кэширования. Работа сервера тоже никуда не исчезла: полученное значение могло служить ключом к данным, сохранённым в другом месте.

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

Судебная запись указывает, что черновой код Cookie находился в репозитории Netscape 3 или 4 октября 1994 года; изменения вносились также 6 и 13 октября. Стороны процесса спорили о точной дате практической реализации. Поэтому надёжная хронология такова: требование клиента и проектирование летом, код в начале октября согласно судебной записи, затем превращение решения в общую функцию браузера Netscape. Единого бесспорного «дня изобретения» нет.

Стандарт появился после браузерного предложения

В феврале 1997 года David Kristol и Montulli опубликовали RFC 2109 «HTTP State Management Mechanism». Документ описывал ответы Set-Cookie и запросы Cookie, предлагая общий синтаксис. Отдельный исторический раздел прямо разбирал совместимость с первоначальным предложением Netscape. Стандартизация означала необходимость учитывать код и поведение, уже распространившиеся на практике.

RFC 2109 не скрывал ограничений механизма. Агент пользователя должен был дать человеку возможность управлять отправкой и сохранением Cookie. Заголовки передавались без защиты, поэтому чувствительное значение могло раскрыться или измениться в пути. Для браузера значение было непрозрачным, но могло оставаться читаемым. В примере входа человек сначала подтверждает себя через форму, а сервер затем возвращает Cookie, отражающий эту идентичность. Cookie продолжает состояние приложения после этого шага, но сам по себе не проверяет, кто находится у браузера.

Это различие важно: сохранённое в браузере значение может помогать сервису, не доказывая, кто им владеет. Если приложение считает обладание значением достаточным полномочием, оно создаёт сессию, доступную предъявителю. Тот, кто получит значение, иногда может повторно использовать его в заданной области и в течение срока действия. Безопасность зависит от способа выдачи, защиты, истечения и отзыва значения; базовый обмен Cookie сам этих вопросов не решает.

История Cookie менее загадочна, чем его название. Торговый процесс вынудил продуктовую команду выбрать, где будет храниться непрерывность. Браузер стал переносчиком состояния, выбранного сервером; запрос клиента превратился в повторно используемую функцию; позднейший стандарт зафиксировал совместимость с уже работающей практикой. Веб-приложения получили возможность помнить транзакцию между отдельными запросами. Но браузер не стал свидетелем человеческой личности за ними.

Источники и пределы доказательств