RFC: 2068
Оригинал: Hypertext Transfer Protocol - HTTP/1.1
Другие версии: RFC 2616
Категория: Предложенный стандарт
Дата публикации:
Авторы: , , , ,
Перевод: Алексей Симонов

19.6. Дополнительные возможности

Эти элементы протокола документов приложения, используемые некоторыми существующими реализациями HTTP, но не последовательно и правильно через большинство HTTP/1.1 приложения. Разработчики должны знать об этих возможностях, но не могут положиться на их присутствие в, или функциональная совместимость с, другой HTTP/1.1 приложения. Некоторые из них описывают предложенные экспериментальные возможности, и некоторые описывают возможности, что экспериментальное развертывание нашло недостаток, к которым теперь обращаются в основном HTTP/1.1 спецификация.

19.6.1. Дополнительные методы запросов

19.6.1.1. PATCH

Метод PATCH похож на PUT за исключением того, что объект содержит список различий между оригинальной версией ресурса, идентифицированного Request-URI и заданным контентом ресурса после того, как действие PATCH было применено. Список различий находится в формате, определенном мультимедийным type объекта (например, "приложение/разность"), и ДОЛЖЕН включить достаточную информацию, чтобы позволить серверу обновлять изменения, необходимые, чтобы конвертировать оригинальную версию ресурса к заданной версии.

Если запрос проходит через кэш, и Request-URI идентифицирует в настоящий момент кэшируемый объект, тот объект ДОЛЖЕН быть удален из кэша. Ответы на этот метод не cachable.

Фактический метод для того, чтобы определить, как исправленный ресурс помещен, и что случается с его предшественником, определен полностью сервером происхождения. Если бы оригинальная версия исправляемого ресурса включала поле заголовка Content-Version, то объект запроса ДОЛЖЕН включить поле заголовка Derived-From, соответствующее значению оригинала поле заголовка Content-Version. Приложения поощрены использовать эти поля для того, чтобы создать связи управления версиями и разрешить конфликты версии.

Запросы PATCH должны повиноваться требованиям передачи сообщения, изложенным в разделе 8.2.

Кэши, которые реализуют PATCH, должны лишить кэшируемые ответы законной силы как определено в разделе 13.10 для PUT.

2007 - 2017 © Русские переводы RFC, IETF, ISOC.