Кратко

  • RFC 2109 стандартизировал Set-Cookie и Cookie, чтобы связать отдельные HTTP-обмены в логическую сессию, не зависящую от постоянного сетевого соединения.
  • Domain, Path, Max-Age, Secure и правила кеша ограничивали состояние; спецификация требовала контроля пользователя и сдерживала автоматические встроенные и перенаправленные запросы.
  • Возврат значения доказывал выбор состояния пользовательским агентом, но не текущего человека, информированное согласие, полномочие, свежесть, намерение транзакции или результат.

Соединение и сессия жили разной жизнью

RFC 2109 прямо определял сессию как логический контекст, а не постоянное сетевое соединение. Соединение могло закончиться, а сессия продолжиться через другое. Живое соединение не означало, что сервер всё ещё принимает старую сессию. Источник начинал её Set-Cookie, агент мог продолжить Cookie, обе стороны могли завершить, а Max-Age=0 требовал удаления.

Тем самым появились три независимых факта: состояние транспорта, сохранённое состояние браузера и серверное решение о действительности сессии. Ни один из них не заменяет другие.

Корзина хранила историю, а не полномочие

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

Значение было непрозрачно для агента, хотя могло читаться при осмотре заголовка. Domain подчинялся историческим правилам сопоставления, Path выбирал префиксы URI, Max-Age задавал желаемый срок, Version=1 обозначал механизм. Одно имя могло вернуться несколько раз для разных подходящих Path. Это правила отбора, не секретности и не авторизации.

Secure был советом

Secure советовал использовать безопасный способ, но пользовательский агент мог сам определить достаточный уровень. Атрибут не шифровал данные, не подтверждал человека и не связывал действие с действующим мандатом. Раздел безопасности отдельно предупреждал о чтении и изменении открытых заголовков.

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

Состояние не должно было уничтожить кеширование

Отделение состояния от URL и документа сохраняло масштабирование через кеши. Публичное представление можно было переиспользовать, а частное содержимое сессии не следовало помещать в общий кеш. Посредник передавал поля и соблюдал срок, private и no-cache="set-cookie".

Поэтому кешированное представление, выданный Set-Cookie, принятая браузером запись и позднее принятое сервером состояние — четыре события. RFC 2068 давал тогдашнюю семантику HTTP/1.1. Старые кеши HTTP/1.0 не умели в общем виде исключать отдельный заголовок и могли опасно сохранить его.

Автоматический повтор уже считался проблемой

RFC 2109 называл транзакцию проверяемой, если пользователь мог заранее увидеть URI. Автоматическая загрузка встроенных объектов и перенаправления обычно были непроверяемыми. Правило пыталось не дать одному источнику без обзора начать или продолжить Cookie-сессию с чужим доменом; исключение должно было быть выключено по умолчанию.

Это не вся современная модель браузерной безопасности, но проблема названа точно: Cookie полезен благодаря автоматическому возврату, а потому сам возврат не выражает нового решения человека.

Пользователь должен был уметь отключить сохранение и отправку, видеть активную сессию, проверять содержимое и управлять хранением по Domain. Спецификация признавала навязчивое отслеживание даже до очевидной личности и возможность позднее связать след с идентифицирующей формой.

RFC 2964 позже сделал акцент на информированном согласии. RFC 2965 заменил RFC 2109 после опыта реализации. RFC 6265 описал распространённую практику, а авторский текст RFC 10025 относится к следующему поколению. Смена документов не доказывает переход конкретного продукта.

Один чек в длинной цепочке

Надёжная запись разделяет глаголы: сервер выдал; агент принял; пользователь сохранил; контекст выбрал; сервер принял сессию; политика разрешила; действие зафиксировано; эффект наблюдался. Заголовок Cookie охватывает лишь часть цепочки.

Running-Code Primacy Лу Хэна возвращает утверждение к исполняемому факту. Minimum Initial Specification оставляет общий слой минимальным. Reality Layers не позволяет одной записи заимствовать власть другой. RFC 2109 стандартизировал память, но не человеческий мандат.

Источники