Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)
Extracted elements (29)
RFC 2518 Section 8.8.4's DELETE-before-COPY rule is clarified: if a resource at the destination has the same resource type as the source, it MUST NOT be deleted but MUST be updated in place. This distinction matters for version history continuity — updating adds to an existing history while replacing creates a new one.
The DAV:expand-property report retrieves properties from resources identified by DAV:href values in a single request, reducing round trips and allowing the server to minimize separate read transactions on the underlying versioning store.
Three basic versioning packages are defined to minimize client complexity: Core-Versioning (version-control only), Basic-Server-Workspace (version-control, workspace, version-history, checkout), and Basic-Client-Workspace (version-control, working-resource, update, label). A server supporting both workspace packages interoperates with all basic versioning clients.
All method marshalling and postconditions defined by RFC 2518 and RFC 2616 continue to hold so that versioning-unaware clients can interoperate with versioning servers. The DAV:auto-version property is specifically designed to support versioning-unaware clients that use PUT/PROPPATCH directly.
A CHECKIN request MUST create a new version with a distinct new URL that MUST NOT ever identify any other resource. The URL for the new version MUST be returned in a Location response header. The content, dead properties, DAV:resourcetype, and DAV:predecessor-set MUST be copied from the checked-out resource.
A CHECKOUT request MUST fail (DAV:must-be-checked-in) if the version-controlled resource does not have a DAV:checked-in property. The response MUST include a Cache-Control: no-cache header.
A COPY request MUST NOT copy versioning properties to the new resource; instead those properties MUST have the default initial values they would have if the resource had been created by a non-versioning method such as PUT or MKCOL.
A DAV:allprop PROPFIND request SHOULD NOT return any of the properties defined by this document, allowing versioning servers to perform efficiently when a naive client issues a DAV:allprop PROPFIND request.
A MOVE request MUST fail if the request-URL identifies a version (DAV:cannot-rename-version precondition). When a resource is moved, versioning properties MUST have the same value at the destination URL as at the source URL.
A PUT or PROPPATCH request MUST fail if the request-URL identifies a version (DAV:cannot-modify-version), and MUST fail if the resource has a DAV:checked-in property unless DAV:auto-version semantics will automatically check out the resource.
An XML element in the DAV namespace MUST NOT be used in the request or response body of a versioning method unless that XML element is explicitly defined in an IETF RFC. This prevents proprietary extensions from polluting the DAV namespace.
If a method precondition or postcondition is not satisfied, the response status MUST be 403 (Forbidden) if the request should not be repeated, or 409 (Conflict) if the user might be able to resolve the conflict. The appropriate XML element MUST be returned as a child of DAV:error in the response body.
If a VERSION-CONTROL request fails, the server state preceding the request MUST be restored. The postcondition DAV:put-under-version-control requires a new version history and version resource to have been created with content, dead properties, and DAV:resourcetype matching the source resource.
If a write-locked resource has a non-computed versioning property, that property value MUST NOT be changed without the appropriate lock token. Every versioning method other than REPORT MUST fail with 423 (Locked) if the resource is write-locked and the token is absent.
The DAV:version-tree report MUST be supported by all version resources and all version-controlled resources. The response body MUST contain a DAV:response element for each version in the version history of the version identified by the request-URL.
The version-control feature MUST be supported if any other versioning feature is supported. A server indicates support by including "version-control" in the DAV response header to OPTIONS requests on any resource that supports versioning properties, reports, or methods.
DAV:auto-version controls automatic checkout/checkin behavior for modification requests on checked-in resources. Valid values are DAV:checkout-checkin, DAV:checkout-unlocked-checkin, DAV:checkout, and DAV:locked-checkout, each controlling when automatic checkout and checkin occur.
DAV:checked-in (protected) appears on a checked-in version-controlled resource and identifies the version that has the same content and dead properties as the resource. It is removed on checkout and re-added on checkin identifying the new version. Defined as <!ELEMENT checked-in (href)>.
DAV:checked-out (protected) appears on a checked-out resource and identifies the version that was in DAV:checked-in at checkout time. It is removed when the resource is checked in. Defined as <!ELEMENT checked-out (href)>.
DAV:checkout-fork and DAV:checkin-fork properties on a version control whether fork creation is DAV:forbidden (CHECKOUT/CHECKIN MUST fail if a fork would result) or DAV:discouraged (MUST fail unless DAV:fork-ok is specified in the request body).
DAV:predecessor-set on a version (protected) identifies each predecessor version via DAV:href elements; the root version has an empty set. On a checked-out resource it determines the predecessor-set of the version created by checkin. Defined as <!ELEMENT predecessor-set (href*)>.
DAV:supported-method-set (protected) identifies all methods supported by a resource. DAV:supported-live-property-set (protected) MUST identify all live properties defined by this document that are supported, and SHOULD identify all supported live properties. DAV:supported-report-set (protected) identifies supported reports.
DAV:version-name (protected) contains a server-defined string that is unique within a version history, intended for display to users. Defined as <!ELEMENT version-name (#PCDATA)>.
The REPORT method is an extensible mechanism for obtaining parameterized information about a resource. The REPORT MUST NOT change any content or dead properties (DAV:no-modification postcondition). If a Depth header is included, the response MUST be a 207 Multi-Status.
Version history provides an audit trail that can be used for accountability. However, the history also captures sensitive information; implementations must ensure that access control policies appropriately restrict who can view version history, creator names, and comments.
Versioning can expose information through security-through-obscurity issues: version URLs are permanent and stable, meaning that a URL that was once visible to a user may remain accessible even after the current version-controlled resource has moved or been restricted.
Versioning increases the need for access control because version history resources, working resources, workspaces, activities, and baselines are additional resources that require appropriate access controls beyond those needed for basic WebDAV.
Versioning introduces denial-of-service risks because unlimited version histories can consume unbounded server storage. Servers should implement policies to bound the number of versions stored per resource or version history.
A version-controlled resource transitions between checked-in (has DAV:checked-in, no DAV:checked-out) and checked-out (has DAV:checked-out, no DAV:checked-in) states. Triggers: CHECKOUT moves checked-in → checked-out; CHECKIN or UNCHECKOUT moves checked-out → checked-in.