Basic WebDAV Concepts

Basic WebDAV Concepts

This section provides a very brief, very general overview to the ideas behind WebDAV. It should lay the foundation for understanding WebDAV compatibility issues between clients and servers.

Original WebDAV

RFC 2518 defines a set of concepts and accompanying extension methods to HTTP 1.1 that make the web into a more universal read/write medium. The basic idea is that a WebDAV-compliant web server can act like a generic file server; clients can mount shared folders that behave much like NFS or SMB filesystems.

The tragedy, though, is that the RFC 2518 WebDAV specification does not provide any sort of model for version control, despite the “V” in DAV. Basic WebDAV clients and servers assume only one version of each file or directory exists, and can be repeatedly overwritten.

Here are the concepts and terms introduced in basic WebDAV:


WebDAV lingo refers to any server-side object (that can be described with a URI) as a resource.

New write methods

Beyond the standard HTTP PUT method (which creates or overwrites a web resource), WebDAV defines new COPY and MOVE methods for duplicating or rearranging resources.


A collection is the WebDAV term for a grouping of resources. In most cases, it is analogous to a directory. Whereas file resources can be written or created with a PUT method, collection resources are created with the new MKCOL method.


This is the same idea present in Subversion—metadata attached to files and collections. A client can list or retrieve properties attached to a resource with the new PROPFIND method, and can change them with the PROPPATCH method. Some properties are wholly created and controlled by users (e.g. a property called “color”), and others are wholly created and controlled by the WebDAV server (e.g. a property that contains the last modification time of a file). The former kind are called dead properties, and the latter kind are called live properties.


A WebDAV server may decide to offer a locking feature to clients—this part of the specification is optional, although most WebDAV servers do offer the feature. If present, then clients can use the new LOCK and UNLOCK methods to mediate access to a resource. In most cases these methods are used to create exclusive write locks (as discussed in the section called “The Lock-Modify-Unlock Solution”), although shared write locks are also possible in some server implementations.

Access control

A more recent specification (RFC 3744) defines a system for defining access control lists (ACLs) on WebDAV resources. Some clients and servers have begun to implement this feature.

DeltaV Extensions

Because RFC 2518 left out versioning concepts, another committee was left with the responsibility of writing RFC 3253, which adds versioning to WebDAV, a.k.a. “DeltaV”. WebDAV/DeltaV clients and servers are often called just “DeltaV” programs, since DeltaV implies the existence of basic WebDAV.

DeltaV introduces a whole slew of new acronyms, but don't be intimidated. The ideas are fairly straightforward:

Per-resource versioning

Like CVS and other version-control systems, DeltaV assumes that each resource has a potentially infinite number of states. A client begins by placing a resource under version control using the new VERSION-CONTROL method.

Server-side working-copy model

Some DeltaV servers support the ability to create a virtual workspace on the server, where all of your work is performed. Clients use the MKWORKSPACE method to create a private area, then indicate they want to change specific resources by “checking them out” into the workspace, editing them, and “checking them in” again. In HTTP terms, the sequence of methods would be CHECKOUT, PUT, CHECKIN.

Client-side working-copy model

Some DeltaV servers also support the idea that the client may have a private working copy on local disk. When the client wants to commit changes to the server, it begins by creating a temporary server transaction (called an activity) with the MKACTIVITY method. The client then performs a CHECKOUT on each resource it wishes to change and sends PUT requests. Finally, the client performs a CHECKIN resource, or sends a MERGE request to check in all resources at once.


DeltaV allows you define flexible collections of resources called “configurations”, which don't necessarily correspond to particular directories. A configuration can be made to point to specific versions of files, and then a “baseline” snapshot can be made, much like a tag.


DeltaV defines a new method, REPORT, which allows the client and server to perform customized data exchanges. While DeltaV defines a number of standardized history reports that a client can request, the server is also free to define custom reports. The client sends a REPORT request with a properly-labeled XML body full of custom data; assuming the server understands the specific report-type, it responds with an equally custom XML body. This technique is very similar to XML-RPC.