RFC 4918

RFC 4918 (англ. Request for Comments 4918) — это документ рабочей группы IETF (Internet Engineering Task Force), определяющий расширение протокола HTTP, известное как WebDAV (Web Distributed Authoring and Versioning). RFC 4918 был опубликован в июне 2007 года и заменил предыдущий стандарт RFC 2518, вышедший в феврале 1999 года. Документ описывает набор методов, заголовков и форматов XML, которые позволяют клиентам выполнять удалённое управление файлами, коллекциями и метаданными на веб-серверах, превращая HTTP из протокола преимущественно для чтения в протокол для совместного редактирования и управления ресурсами.

История и предпосылки создания

В середине 1990-х годов развитие Всемирной паутины выявило потребность в инструментах для удалённого редактирования и совместной работы над документами, размещёнными на веб-серверах. Существующий протокол HTTP/1.1 (RFC 2616) предоставлял только методы GET (чтение) и POST (отправка данных), но не поддерживал операции блокировки, переименования, копирования или управления версиями. Для решения этой проблемы в 1996 году была создана рабочая группа IETF WebDAV.

Первая версия спецификации, RFC 2518, была утверждена в феврале 1999 года. Она ввела основные методы WebDAV (PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK) и определила формат XML для представления свойств ресурсов. Однако со временем были выявлены недостатки, связанные с неоднозначностью в обработке блокировок, отсутствием поддержки некоторых операций и проблемами с обратной совместимостью. RFC 4918, разработанный под руководством Лизы Дюссо (Lisa Dusseault), устранил эти недочёты, уточнил семантику методов и ввёл новые возможности, такие как поддержка блокировок с ограниченной глубиной и улучшенная обработка коллекций.

Основные методы и расширения

RFC 4918 определяет семь новых HTTP-методов, дополняющих стандартные GET, PUT, DELETE и POST. Все методы, кроме LOCK и UNLOCK, являются идемпотентными — повторное выполнение запроса с теми же параметрами не изменяет состояние сервера.

PROPFIND и PROPPATCH

Метод PROPFIND используется для получения свойств (свойств) ресурса или коллекции. Клиент отправляет XML-запрос с указанием глубины поиска (0 — только сам ресурс, 1 — ресурс и его непосредственные дочерние элементы, infinity — все вложенные элементы). Сервер возвращает XML-ответ, содержащий запрошенные свойства, такие как дата создания, размер, тип MIME, а также пользовательские свойства, определённые администратором.

Метод PROPPATCH позволяет устанавливать или удалять свойства ресурса. Запрос содержит XML-тело с операциями set (установить значение) или remove (удалить свойство). Это даёт возможность серверу хранить произвольные метаданные, например, автора документа, статус рецензирования или ключевые слова.

MKCOL

Метод MKCOL (make collection) создаёт новую коллекцию (аналог директории) на сервере. В отличие от обычного создания ресурса через PUT, MKCOL гарантирует, что создаётся именно контейнер для других ресурсов, а не файл. Если коллекция уже существует, сервер возвращает ошибку 405 (Method Not Allowed).

COPY и MOVE

Метод COPY копирует ресурс или коллекцию в указанное место назначения. Запрос включает заголовок Destination (целевой URI) и может содержать заголовок Depth для указания глубины копирования вложенных элементов. При копировании коллекции все её дочерние ресурсы также копируются рекурсивно.

Метод MOVE перемещает ресурс или коллекцию. Он работает аналогично COPY, но после успешного перемещения исходный ресурс удаляется. Если целевой URI уже существует, сервер может перезаписать его (при наличии соответствующего заголовка Overwrite).

LOCK и UNLOCK

Метод LOCK позволяет клиенту заблокировать ресурс или коллекцию для предотвращения одновременного редактирования. RFC 4918 различает два типа блокировок:

• Эксклюзивная блокировка (exclusive lock) — только один клиент может изменять ресурс.
• Разделяемая блокировка (shared lock) — несколько клиентов могут одновременно иметь блокировку, но все они должны согласовывать изменения.

Блокировка может быть глубокой (deep lock), распространяющейся на все дочерние элементы коллекции, или неглубокой (shallow lock), действующей только на сам ресурс. Клиент может снять блокировку методом UNLOCK, передав токен блокировки в заголовке Lock-Token.

Формат XML и свойства ресурсов

Все запросы и ответы WebDAV, за исключением некоторых простых операций, используют формат XML. RFC 4918 определяет пространство имён DAV: для элементов и атрибутов, описывающих свойства, блокировки и состояния. Основные элементы XML включают:

• <prop> — контейнер для набора свойств.
• <propertybehavior> — инструкция для сервера о том, как обрабатывать свойства (например, propfind или proppatch).
• <lockentry> — описание типа блокировки (эксклюзивная/разделяемая) и её глубины.
• <activelock> — информация о текущей активной блокировке, включая токен, владельца и время истечения.

Свойства ресурсов делятся на живые (live properties), которые вычисляются сервером динамически (например, DAV:getcontentlength — размер файла), и мёртвые (dead properties), которые задаются клиентом и хранятся как есть (например, DAV:displayname — отображаемое имя).

Применение и значение

WebDAV, реализованный в соответствии с RFC 4918, нашёл широкое применение в нескольких областях:

Совместная работа и управление документами

Протокол используется в системах управления контентом (CMS), таких как Microsoft SharePoint, Alfresco и Nextcloud, для удалённого редактирования документов, загрузки файлов и управления версиями. Клиенты, такие как Microsoft Office (через протокол WebDAV) или файловые менеджеры (например, Nautilus в Linux), позволяют пользователям работать с файлами на сервере так же, как с локальными.

Версионирование и управление исходным кодом

Хотя RFC 4918 не определяет механизмов версионирования, он служит основой для более специализированных протоколов, таких как DeltaV (RFC 3253). Некоторые системы контроля версий, например, Subversion (SVN), используют WebDAV для транспорта данных, позволяя клиентам выполнять операции commit, update и diff через HTTP.

Календари и контакты

Протокол CalDAV (RFC 4791), расширяющий WebDAV, используется для управления календарями (например, в Apple iCloud или Google Calendar). Аналогично, CardDAV (RFC 6352) применяется для синхронизации контактов. Оба протокола опираются на методы и структуры, определённые в RFC 4918.

Облачные хранилища

Многие облачные сервисы, включая Яндекс.Диск и Box, поддерживают WebDAV как альтернативный способ доступа к файлам, помимо собственных API. Это позволяет интегрировать их с любыми клиентами, поддерживающими протокол, без необходимости писать специальные адаптеры.

Критика и ограничения

Несмотря на широкое распространение, RFC 4918 имеет ряд недостатков, которые критикуются сообществом разработчиков и администраторов:

• Сложность реализации. Полноценная поддержка WebDAV требует от сервера обработки сложных XML-запросов, управления блокировками и состоянием коллекций. Многие реализации (например, в Apache HTTP Server) являются неполными или имеют ошибки.
• Производительность. Использование XML для передачи метаданных увеличивает объём трафика и нагрузку на процессор. Для больших коллекций запросы PROPFIND могут быть медленными.
• Безопасность. Блокировки, особенно глубокие, могут быть использованы для атак типа «отказ в обслуживании» (DoS), если клиент удерживает блокировку неопределённо долго. RFC 4918 рекомендует устанавливать тайм-ауты, но не обязывает серверы их принудительно применять.
• Отсутствие поддержки версионирования. Как упоминалось, RFC 4918 не включает механизмов управления версиями, что вынуждает разработчиков использовать дополнительные протоколы (DeltaV) или реализовывать версионирование на уровне приложения.

Влияние на последующие стандарты

RFC 4918 стал основой для нескольких расширений, разработанных рабочей группой IETF WebDAV:

• RFC 3253 (DeltaV) — добавляет поддержку версионирования, управления конфигурациями и рабочего пространства.
• RFC 3744 (WebDAV Access Control) — определяет механизмы контроля доступа на основе списков ACL.
• RFC 4791 (CalDAV) — расширяет WebDAV для работы с календарями.
• RFC 6352 (CardDAV) — расширяет WebDAV для работы с адресными книгами.

В 2020 году IETF опубликовала RFC 8889, который уточняет некоторые аспекты блокировок в WebDAV, но не заменяет RFC 4918.

Источники

• RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV). IETF, 2007.
• RFC 2518: HTTP Extensions for Distributed Authoring — WEBDAV. IETF, 1999.
• Dusseault, L. (2003). WebDAV: Next-Generation Collaborative Web Authoring. Prentice Hall.
• IETF WebDAV Working Group. (1996–2007). Протоколы и обсуждения.
• Документация Apache HTTP Server: модуль mod_dav.