Кратко

  • Для каждой блокировки WebDAV сервер создаёт уникальный токен. Его присутствие в поле If доказывает передачу идентификатора, но не личность отправителя, право записи или сохранность блокировки.
  • Корректное изменение проходит независимые проверки: аутентификацию принципала, полномочие на метод, полный набор затронутых ресурсов, условия и ETag, прямые и косвенные блокировки, связь с создателем или разрешённым override и состояние при commit.
  • Общие блокировки, бесконечная глубина коллекций, COPY/MOVE и выбранный сервером timeout не позволяют считать токен переносимой арендой. Это ограниченное свидетельство координации.

Одна удалённая блокировка — не свободный ресурс

Три редактора ставят shared lock на один ресурс. Сервер создаёт три блокировки и три разных токена. Первый редактор завершает работу и отправляет UNLOCK. Сервер удаляет ровно указанную блокировку. Две другие остаются.

Если интерфейс хранит одно поле locked=true, он ещё может отобразить реальность. Если же он считает успешный UNLOCK переходом в false, операционная модель теряет множественность, которую протокол сохраняет намеренно.

Та же ошибка встречается в авторизации. Токен совпадает — значит, предъявитель якобы владеет блокировкой и имеет право писать. Но RFC 4918 требует при изменении заблокированного ресурса проверять, что аутентифицированный принципал совпадает с создателем блокировки, помимо корректной передачи токена. Наличие lock также не даёт полного права изменения. Обычные механизмы аутентификации и привилегий остаются обязательными.

Токен указывает, какую координационную запись знает запрос. Он не устанавливает личность, не выдаёт привилегию, не вычисляет область метода и не гарантирует текущую версию состояния.

Строгая уникальность не равна делегированию

WebDAV добавляет к HTTP удалённое редактирование, свойства, коллекции, операции пространства имён и предотвращение конфликтов. Write lock прежде всего снижает риск lost update, когда один автор незаметно переписывает изменения другого.

Каждая блокировка имеет ровно один уникальный токен, созданный сервером. Клиент не должен интерпретировать структуру. RFC 4918 требует уникальности URI токена для всех ресурсов и на всё время. Новый LOCK возвращает значение в response header Lock-Token и в теле.

Уникальность не даёт перепутать две записи, но не предоставляет власть. Активные блокировки могут быть доступны через DAV:lockdiscovery, поэтому секретность значения сама по себе не является контролем доступа.

Стандарт рекомендует UUID URN, сохраняет постоянно зарегистрированную схему opaquelocktoken и допускает другую уникальную URI. RFC 9562 советует криптографически стойкий генератор псевдослучайных чисел, когда важна непредсказуемость. Она мешает угадыванию, но не проверяет DAV:write-content, DAV:bind или бизнес-политику.

Полезно разделять шесть функций: уникальность различает locks; непредсказуемость снижает обнаружение; предъявление показывает знание значения; аутентификация связывает запрос с принципалом; авторизация определяет действие; исполнение меняет актуальное состояние. Токен не должен присваивать три последние функции.

Создатель lock не становится владельцем ресурса

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

RFC 3744 делит общее слово «запись». DAV:write-content регулирует изменение существующего содержимого, DAV:write-properties — properties, DAV:bind — добавление member в collection, DAV:unlock — UNLOCK не владельцем блокировки. PUT на ещё не сопоставленную URI зависит от bind-привилегии родительской коллекции.

Пользователь с write-правом не может игнорировать чужую блокировку. Предъявитель токена не может игнорировать ACL. Административное снятие должно быть отдельным разрешённым и атрибутированным override, а не воображаемым владением.

Различие Heng Lu между записью и властью точно описывает этот механизм. Токен фиксирует полезное состояние координации. Практическая власть остаётся у систем, которые устанавливают личность, оценивают политику, разрешают пространство имён, записывают хранилище и проводят восстановление.

Поле If: условие и предъявление одновременно

У WebDAV If две роли. Как условное поле оно описывает state tokens и ETags. Условия внутри одного списка соединены AND, несколько списков являются OR-альтернативами, Not отрицает следующий элемент. Untagged list относится к Request-URI, tagged list явно называет ресурс.

Одновременно появление токена в If считается его предъявлением серверу. Этот факт сохраняется, даже если истинной итоговую формулу сделала другая альтернативная группа. Для методов с несколькими ресурсами важно отдельно выразить условия и передать все необходимые токены.

Gateway, который сохраняет только «победившую ветвь», может удалить нужное значение. Лог с записью «token present» способен скрыть ложный ETag. Следует отдельно фиксировать предъявленные значения, оценённые списки, их ресурсы и результат.

Ошибки 412 и 423 также различны. Ложное If приводит к 412 Precondition Failed после проверки авторизации. Если для затронутого заблокированного ресурса не предъявлен обязательный токен, 423 Locked с lock-token-submitted описывает нехватку. В первом случае не выполнено утверждение о состоянии; во втором нет требуемого lock-свидетельства.

Header Lock-Token уже по назначению: он возвращает новый токен в успешном LOCK и обозначает удаляемую блокировку в UNLOCK. PUT, PROPPATCH, COPY, MOVE и DELETE предъявляют state tokens в If.

Видимая URI — не весь набор воздействия

У блокировки есть root, scope, type и depth. Прямая блокировка возникает на корневой URL. Depth-infinity lock коллекции косвенно действует на потомков и будущих members.

Файл может быть ограничен lock родительской коллекции, хотя интерфейс не показывает локальной блокировки. Сервер обязан разрешить актуальную карту имён и собрать все применимые состояния.

LOCK допускает Depth 0 или infinity, по умолчанию infinity. Если несовместимый descendant мешает заблокировать иерархию, частично заблокированное дерево оставлять нельзя. Запрошенная область срабатывает целиком либо не срабатывает; Multi-Status может указать препятствие.

COPY, MOVE и DELETE затрагивают источник, назначение, родителя и иногда перезаписываемый ресурс. Все обязательные токены для этого набора должны быть предъявлены.

MOVE особенно ясно показывает, почему токен не переносится вместе с содержимым. Прямая блокировка не следует на новую URL. Ресурс может выйти из косвенной области источника и войти в depth-infinity lock назначения. Значение определяется текущим пространством имён, а не постоянным правом внутри файла.

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

Shared означает несколько самостоятельных блокировок

Shared lock допускает совместимые shared locks. Однако каждый успешный LOCK создаёт отдельную запись и отдельный токен. У трёх сотрудников нет общего пароля.

Refresh одной блокировки не продлевает другие. UNLOCK удаляет указанную, но не гарантирует свободу ресурса: остаются другие shared или косвенные locks.

Merge, review, порядок и разрешение разногласий определяет приложение. WebDAV определяет техническую совместимость. Слово shared не создаёт коллективное владение или голосование.

Интерфейс должен показывать создателя, root, depth, прямое или наследуемое отношение, timeout и фактический эффект каждого UNLOCK. Один индикатор скрывает ключевые различия.

Срок выбирает сервер

Клиент может предложить длительность в Timeout, но сервер выбирает выданное значение и вправе проигнорировать или изменить запрос.

Refresh выполняется LOCK без тела с одним токеном в If. Сервер игнорирует Depth, при успехе перезапускает таймер, не меняет соседние shared locks и возвращает обновлённый DAV:lockdiscovery. Новый Lock-Token не выдаётся.

Ошибка refresh не считается успехом. До локально вычисленного срока lock не гарантирован: override, crash или потеря состояния могут удалить его. И пересечение локальной отметки не доказывает, что сервер уже выполнил очистку.

Timeout — обязанность обновления и механизм уборки, не жёсткая аренда. Перед важным commit клиент снова предъявляет токен, а сервер решает по актуальному lock, версии и политике.

Восстанавливаемая цепочка записи

Надёжная реализация разделяет:

  1. аутентификацию принципала;
  2. авторизацию точного действия;
  3. разрешение источника, назначения, родителей и overwrite-целей;
  4. поиск прямых, косвенных, exclusive и shared locks;
  5. полный разбор If, tags, ETags, Not и альтернатив;
  6. подтверждение всех необходимых tokens;
  7. связь принципала с создателем или разрешённым override;
  8. новую проверку состояния при commit и требуемую атомарность;
  9. раздельную запись ошибок личности, права, условия, токена, scope и исполнения.

Вместо сырого значения можно хранить keyed fingerprint. Минимальная доказательная цепочка включает принципал, метод, ресурсы, roots, depths, решение, фактический timeout, финальную версию и статус.

Тесты должны пересекать границы: правильный токен с другим принципалом; право без токена; токен с ложным ETag; новый member под бесконечным lock; отказ иерархического LOCK без частичного следа; MOVE без переноса прямой блокировки и с применением destination lock; несколько shared locks с refresh или удалением только одного; атрибутированный admin override; альтернативная запись без тихого обхода.

WebDAV уменьшает один класс потерянных обновлений. Он не решает бизнес-deadlock, смысловой merge, прямой доступ к storage или распределённую транзакцию. Узкая общая спецификация остаётся сильной, пока ей не приписывают лишнюю власть.

Источники