Summary

  • Пятая редакция проекта Byte Range PATCH предупреждает: сервер может проигнорировать Content-Range в PUT и заменить ресурс целиком присланным фрагментом.
  • Формат message/byterange включает в документ PATCH один непрерывный диапазон записи. При неизвестном диапазоне сервер обязан отказать с кодом 400 или 422.
  • Указанная длина части должна в точности совпасть с диапазоном. Сервер, допускающий разреженные файлы, не вправе раскрывать неинициализированные данные.

В проекте есть короткий опыт с двенадцатью байтами. Исходный файл содержит 0123456789 и конец строки. Клиент хочет положить wxyz на места со 2-го по 5-е. Правильный результат — 01wxyz6789 и прежний конец строки. При обычной замене PUT результатом могут стать только wxyz. Операция с четырьмя байтами отняла остальные восемь, хотя клиент ясно написал нужную позицию.

Причина в том, что позиция и обязанность её соблюдать живут на разных сторонах соединения. Раздел 2 проекта говорит: частичный PUT с Content-Range требует специальной поддержки сервера. Если её нет, сервер может пропустить поле и заменить ресурс. Передача прошла успешно. Согласия на конкретную операцию не было.

Предлагаемый PATCH кладёт инструкцию в документ с определённым типом. message/byterange описывает один диапазон, multipart/byteranges — несколько, а application/byteranges даёт двоичную форму. Для первого типа внутри тела находится Content-Range: bytes 2-5/12 и сами wxyz. Сервер, поддерживающий формат, выполняет запись по позиции. Незнакомый формат следует отвергнуть до изменения файла. Явный отказ дешевле тихой потери данных.

Диапазон проверяется до первого изменения

Каждая часть должна назвать один непрерывный участок. Если положение неизвестно, ответом должны быть 400 или 422. Если часть содержит Content-Length, число обязано точно соответствовать длине диапазона. Такая проверка лишает сервер возможности решать наугад, куда поместить лишний байт. Для потока с неизвестным концом есть Content-Offset: он всё равно задаёт начальную позицию записи.

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

Отдельный раздел предлагает Prefer: transaction=atomic и transaction=persist для случая разрыва передачи. Серверу рекомендуется сообщать о выполненном предпочтении через Preference-Applied. Это выбор между фиксацией после успеха и сохранением уже принятых данных. Но сначала требуется договориться, что пришедший фрагмент — часть файла, а не весь новый файл.

RFC 5789 позволяет объявить поддерживаемые типы PATCH через Accept-Patch. Для оценки внедрения не хватает открытого опыта с одинаковыми PUT по диапазону и PATCH message/byterange на разных серверах: исходные и конечные байты, статус и ETag показали бы, кто понял команду.

Проект и его статус · RFC 5789 · RFC 9110