Content-Digest и Repr-Digest HTTP: проверить правильный набор байтов
Фотография конкретного исполнения не приложена.
Content-Digest относится к фактическому содержимому HTTP-сообщения, Repr-Digest — ко всему выбранному представлению. Различие существенно при Range, HEAD и других случаях, когда переданное содержимое не совпадает с полным объектом. Нельзя сравнивать хэш одного полученного сегмента с digest полного представления и трактовать несовпадение как доказательство повреждения канала.
Поля используют структуру Dictionary: ключ задаёт алгоритм, значение — кодированную последовательность байтов digest. Это не произвольная строка шестнадцатеричного числа. Парсер должен учитывать предусмотренный формат, доступные алгоритмы и область проверки, а не извлекать символы по знакомому имени заголовка.
Само наличие digest не означает, что клиент его проверил. RFC допускает разные локальные политики обработки, поэтому приложение должно явно определить обязательность результата перед использованием файла. Также сохраняют этап преобразований данных, к которому относится проверка, чтобы не смешивать представление, содержимое сообщения и выбранный локальный формат.
В приёмке используют полное представление, сегмент и контролируемое изменение байта тестовых данных. Проверяют различимый отказ и правильную область расчёта. Успешное сетевое завершение или присутствующий заголовок digest не являются подтверждением выполненной проверки целостности получателем.
Основание — Selected IETF HTTP RFCs, exact numbered editions and sections cited, разделы RFC9530 §2 Content-Digest; §3 Repr-Digest. Сохранён текст публичной справочной публикации; конкретная реализация может поддерживать только часть возможностей. Реальные зоны, resolver и HTTP-клиенты не испытывались. Это проектные критерии; номера RFC обозначают документы, а не подтверждённую поддержку всех возможностей конкретным устройством.
Запросы отправляются на наш e-mail из вашей почтовой программы.
