Кратко

  • digest-mismatched-values допускает, что запрос мог быть непреднамеренно изменен посредником и что при временной транспортной проблеме отправитель мог бы повторить его без изменений. Это гипотеза, а не установленная причина.
  • RFC 9110 советует не повторять автоматически неудавшийся автоматический retry и запрещает proxy автоматически повторять неидемпотентный запрос. Следующая попытка требует прикладного доказательства, а не еще одного толкования той же ошибки.

Первый ответ сообщил digest-mismatched-values. Клиент решил, что байты временно изменил посредник, и отправил тот же запрос еще раз. Второй ответ сообщил тот же тип, для того же Content-Digest и алгоритма. Автомат воспринял совпадение как подтверждение нестабильного канала и отправил третий запрос.

Логика должна была быть противоположной. Неудача первой автоматической попытки не усилила гипотезу о временной причине. Она показала, что простейшее объяснение не подтверждено, а неопределенность прикладного результата стала больше.

Проект HTTP Problem Types for Digest Fields действительно говорит, что запрос, возможно, был непреднамеренно изменен посредником и что отправитель мог бы повторить неизменный запрос при временной проблеме передачи. Но модальные слова сохраняют границу доказательства. Ответ сообщает о несовпадении вычислений. Он не называет виновника, не подтверждает временность и не удостоверяет, что предыдущая операция не была применена.

Исследование фиксирует revision 06 от 24 июня 2026 года со сроком до 26 декабря 2026 года. На 2 октября Datatracker показывал рабочий документ группы HTTPAPI в очереди RFC Editor, в состоянии Awaiting First Editor. Ответственным Area Director был Mike Bishop; по линии IANA требуемые действия имели отметку RFC-Ed-Ack. Документ предназначен для Standards Track как Proposed Standard, но номера RFC еще не получил. Состояние публикации не доказывает внедрение и не отменяет необходимость фиксировать версию семантики.

Несовпадение — это результат сравнения, не рассказ о причине

digest-mismatched-values применяется, когда предоставленное значение достаточно корректно для сравнения, но не совпадает с digest, который сервер вычислил для соответствующего поля. Элемент может назвать algorithm, provided_digest и header.

Серверное вычисленное значение намеренно не передается: проект не определяет способ его сообщить, чтобы не создавать oracle. Следовательно, клиент не получает полного протокола сверки. Он знает о неравенстве, но не видит второй результат и точную последовательность байтов, использованную на стороне ответчика.

Причин остается несколько. Отправитель мог хешировать не тот диапазон. Content coding или допустимое преобразование могли изменить байты. Посредник мог внести непреднамеренное изменение. Могло произойти повреждение. Компоненты могли проверять разные поля. Повторение одного и того же симптома не выбирает одну причину автоматически.

Два соседних типа требуют иной реакции

digest-unsupported-algorithms означает, что валидатор не поддерживает предложенные алгоритмы для названного поля. В ответе могут быть сведения о поддерживаемых вариантах и их предпочтении. Это помощь в выборе совместимого вычисления, но не обещание допуска следующего запроса.

digest-invalid-values означает, что значение не могло быть результатом заявленного алгоритма, например из-за невозможной длины SHA-512. Неизменный повтор здесь, скорее всего, снова даст ошибку, потому что дефект в вычислении или кодировании. Ошибка разбора Structured Fields возникает еще раньше и не должна смешиваться с невозможной формой digest.

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

Повтор имеет собственную семантику

RFC 9110 отделяет идемпотентность от успешности. Идемпотентный метод можно безопаснее повторить после сбоя соединения, поскольку повтор того же намерения имеет тот же предполагаемый эффект, хотя ответы могут отличаться. Но клиент не должен автоматически повторять неидемпотентный запрос, если не знает, что фактическая семантика идемпотентна, или не может определить, что первая попытка не была применена.

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

В примерах Digest-проекта встречаются PUT и POST. Тип ошибки не присваивает методу новую семантику. POST с устойчивым idempotency key и журналом операции может быть безопасно повторяемым. Тот же POST с новой идентичностью — другая операция. Даже PUT может иметь условные или внешние эффекты, которые надо учитывать.

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

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

RFC 9530 различает Content-Digest для HTTP content и Repr-Digest для выбранного представления. Кодирование содержимого и преобразования могут менять байтовые области. Отдельный активный Internet-Draft Unencoded-Digest предлагает еще одну область для некодированного содержимого и на дату исследования не является RFC.

Поэтому header — обязательная часть смысла диагностического элемента. Если запись хранит лишь SHA-256 и mismatch, следующий retry может исправить вычисление для неправильной области. Точное число без области превращается в неточное свидетельство.

Несколько Digest или preference fields могут дать несколько элементов. Порядок массива не задает приоритет. Расширения необязательны, а их отсутствие не имеет специального значения. Второй ответ с меньшим числом деталей не доказывает, что остальные проблемы исчезли; сервер мог просто раскрыть меньше.

Problem Details не закрывает прикладную операцию

RFC 9457 определяет машиночитаемое описание проблем. Тип называет класс, расширения добавляют контекст. Поле status внутри JSON, если оно есть, носит рекомендательный характер и может расходиться с реальным HTTP status после вмешательства посредника.

Полученный 400 не удостоверяет отсутствие побочных эффектов во всей распределенной системе. CDN, шлюз, аудит, очередь и origin могут действовать в разном порядке. Один компонент способен создать запись или резерв до того, как другой обнаружит Digest-ошибку. Сам problem type не стандартизирует этот граф исполнения.

Значит, автомату нужен внешний источник истины: idempotency key, transaction ID, conditional request, долговременная квитанция отказа или запрос состояния. Если результат неизвестен, правильное состояние — reconciliation, а не очередной replay.

Подробность ответа имеет цену

Отказ возвращать вычисленный digest уменьшает риск oracle, но другие детали тоже раскрывают инфраструктуру. Списки алгоритмов, причины, названия полей и различия между маршрутами могут fingerprint-ить реализацию или показать наличие посредника. Повторенный provided_digest может разойтись по логам, тикетам и внешней телеметрии.

Оператор вправе выбрать более общий problem type. Клиент должен сохранять отсутствие деталей как неизвестность, а не как отрицание. Для корреляции часто достаточно защищенного fingerprint; исходное значение можно хранить отдельно с ограниченным доступом.

Без этой дисциплины retry-цикл становится еще и каналом разведки: повторяющиеся запросы провоцируют разные ответы, а система собирает внутренние возможности сервера. Это плохая замена как диагностике, так и согласованию протокола.

Минимальный автомат с явным остановом

В терминах слоев реальности Heng Lu Digest — символическое утверждение о названных байтах. Problem Details — заявление валидатора. Retry — новое действие. Коммит приложения и пользовательский результат — последующие наблюдения. Нижний слой не может сам выдать себе полномочие на верхний.

Minimum Initial Specification должна хранить устойчивый operation ID, метод, цель, номер и предел попыток, источник idempotency authority, Digest header, алгоритм, защищенный fingerprint, точку проверки, HTTP status, problem type, происхождение ответа и прикладную квитанцию. Состояние unknown нельзя заменять на not_applied.

Running-Code Primacy требует проверить временное преобразование, устойчивую ошибку области, невозможную длину, несколько полей, пропавшие расширения и потерянный ответ после commit. Затем первая автоматическая попытка должна завершиться ошибкой, а система — остановиться без третьего запроса. Для POST без ключа останов должен сработать еще раньше.

Машиночитаемая ошибка полезна, когда уменьшает пространство возможных причин. Она опасна, когда то же уменьшение принимают за полномочие действовать. Второй mismatch — не повод сильнее нажать на кнопку; это сигнал, что кнопка больше не располагает доказательствами.

Источники