Кратко

  • RFC 10025 предписывает производителю более строгий профиль, а потребителю — более терпимый разбор ради совместимости. Даже корректная строка Set-Cookie может быть проигнорирована, отвергнута, нормализована, заменена или удалена до следующего запроса.
  • Хранение не гарантирует отправку, а отправка не предоставляет разрешение. Жизненный цикл следует связывать отдельными квитанциями без записи значения cookie или секрета сессии.

Представим восстановленную, а не реальную аварию. Служба входа возвращает ожидаемый ответ по TLS и две отдельные строки Set-Cookie. Сетевой контроль видит обе и закрывает проверку. Затем один клиент приходит без идентификатора, а другой присылает две одноимённые пары.

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

RFC 10025, стандарт IETF от июля 2026 года, отменивший RFC 6265, проводит именно эту границу. Ответ Set-Cookie передаёт имя, значение и атрибуты. Позднейший Cookie содержит выбранные пары. Он не возвращает подтверждение допуска и не несёт историю локального состояния.

Асимметрия нужна для совместимости

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

Серверная проверка доказывает качество исходной инструкции. Она не знает движок потребителя, редакцию политики, контекст получения и ветвь алгоритма хранения. Его первый шаг прямо разрешает агенту пользователя полностью игнорировать полученный cookie. «Получен» означает лишь вход в обработку.

Ответственность также распределена. Приложение составляет поле. HTTP-стек переносит отдельные строки. Агент пользователя разбирает и хранит. Пользователь или администратор меняет ограничения. Навигация, вложенный документ, worker или не-HTTP API создаёт новый контекст. Лишь затем служба проверяет сессию и полномочия.

Допуск создаёт новую локальную запись

Алгоритм отвергает запрещённые управляющие символы, слишком длинную пару имени и значения, недопустимый Domain и несогласованные условия атрибутов или префиксов. SameSite=None требует Secure. Имена __Secure- и __Host- получают заявленные свойства только при выполнении условий. Агент пользователя сверяет префиксы без учёта регистра, чтобы серверная нечувствительность к регистру не породила ложную гарантию.

Допущенная строка превращается в структуру: имя, значение, фактический срок, домен, путь, время создания и последнего доступа, признаки persistent, host-only, secure-only, http-only и same-site. Max-Age имеет приоритет над Expires. Отсутствие Domain даёт привязку только к хосту. Замена определяется сочетанием имени, домена и пути, а не именем отдельно.

Следовательно, отправленный текст и сохранённое состояние требуют разных доказательств. Безопасная диагностика хранит отпечаток инструкции без секрета, вердикт допуска, ограниченный класс отказа и нормализованную область. Иначе синтаксис, политика, корректная замена и неверная область сливаются в одно «cookie пропал».

Срок — предел, а не обязательство хранить

Expires и Max-Age выражают желаемый максимум. Они не резервируют место. Агент пользователя может ограничить фактический срок, удалить истёкшие записи и вытеснить избыток при локальном пределе на домен или весь магазин. Пользователь способен удалить данные, политика — сократить хранение, а непостоянные записи исчезают при завершении сессии по местному определению.

Поэтому дата через год не доказывает год хранения. Для этого нужен отдельный факт: фактическое истечение, замена, явное удаление, окончание сессии, нехватка ёмкости или очистка политикой. RFC советует серверам корректно деградировать, когда cookie не возвращается, поскольку запись может быть удалена в любой момент.

На управляемом устройстве причина может оставаться в локальном аудите. Публичный сайт не должен требовать полный частный журнал. Допустимы грубые категории, агрегаты и диагностика с согласием. Наблюдаемость не оправдывает централизацию cookie, bearer-токена, секрета сессии или посторонней истории посещений.

Выбор заново выполняется для каждого запроса

Хранящаяся запись должна соответствовать URI, same-site-статусу и типу извлечения. Истечение, хост или домен, путь, защищённый канал, HttpOnly и SameSite могут исключить её. Политика агента пользователя способна опустить всё поле Cookie.

WHATWG Fetch включает cookies в credentials веб-запроса. document.cookie в HTML — не-HTTP поверхность и не получает доступ через HttpOnly. Документы верхнего уровня и их предки, перезагрузки, общие и сервисные workers дают разные основания для вычисления «site for cookies». Одного конечного URL недостаточно.

SameSite тоже не является согласием. Strict, Lax, None и Default зависят от контекста. Для недавней Default-записи агент пользователя может применить краткое поведение Lax-allowing-unsafe. RFC считает SameSite дополнительной защитой, а не универсальным средством от CSRF, и подчёркивает: атрибут выбирает сервер, а не пользователь.

Обратно приходит пара, а не её происхождение

Запрос обычно содержит имя и значение. Domain, Path, SameSite, время создания и причина выбора не возвращаются. Одноимённые записи с разными путями или доменами могут сосуществовать, а их порядок не следует считать деловым приоритетом.

HTTP/2 и HTTP/3 позволяют переносить одну логическую cookie-строку в нескольких строках поля. Такое представление не восстанавливает историю магазина.

После доставки приложение отдельно разбирает данные, ищет сессию, проверяет истечение, отзыв и ротацию, аутентифицирует участника, оценивает CSRF-защиту и разрешает метод для ресурса. RFC 9110 задаёт семантику HTTP, но не выдаёт местное полномочие.

RFC 10025 называет cookie ambient authority. Третья сторона может инициировать запрос, после чего агент пользователя автоматически добавит неизвестный инициатору секрет. Наличие cookie не доказывает намерение пользователя. Отсутствие не доказывает сознательный отказ: причиной может быть область, политика, срок или ёмкость.

Шесть связанных квитанций

Выпуск фиксирует URL ответа, время, упорядоченные и не объединённые Set-Cookie, версию конфигурации и отпечаток без значения. Допуск фиксирует потребляющий движок, действующую политику, результат разбора и класс отказа. Хранение фиксирует нормализованную область, флаги, фактический срок, заменяемую запись и обращение со временем создания.

Удержание фиксирует истечение, удаление, конец сессии, замену или вытеснение там, где наблюдение правомерно. Извлечение связывает URI, метод, инициатор, верхний контекст, расчёт SameSite и непрозрачные ID включённых или удержанных записей. Приложение разделяет разбор, поиск сессии, аутентификацию, CSRF-контроль, авторизацию и итог.

Это предложение Daniel Kade по управлению, а не телеметрия, требуемая RFC 10025. Оно не требует от публичного браузера раскрыть хранилище и не записывает секреты.

Так применяется принцип Heng Lu о работающем коде как первичном доказательстве. Policy Mirror показывает владельца каждого решения и не превращает пожелание сервера в факт клиента. Именно так реальность остаётся продуктом вместо адвокации.

Источники