C.1 Basic WebDAV Concepts

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

C.1.1 Just Plain 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 WebDAV shares that behave much like NFS or SMB shares.

However, it's important to note that RFC 2518 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.^[1]

^[1] For this reason, some people jokingly refer to generic WebDAV clients as WebDA clients!

Here are the new concepts and methods introduced in basic WebDAV:

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.

Collections

This is simply the WebDAV term for a grouping of resources (URIs). In most cases, it is analogous to a directory. You can tell something is a collection if it ends with a trailing /. Whereas file resources can be written or created with a PUT method, collection resources are created with the new MKCOL method.

Properties

This is 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.

Locking

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 Section 2.2.2), although shared write locks are also possible.

C.1.2 DeltaV Extensions

Because RFC 2518 left out versioning concepts, another capable group was left with the responsibility of writing RFC 3253, which adds versioning to WebDAV. WebDAV/DeltaV clients and servers are often called just DeltaV clients and servers, 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. Here are the new concepts and methods introduced in DeltaV:

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. This creates a new Version Controlled Resource (VCR). Every time you change the VCR (via PUT, PROPPATCH, etc.), a new state of the resource is created, called a Version Resource (VR). VCRs and VRs are still ordinary web resources, defined by URLs. Specific VRs can have human-friendly names as well.

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 VCRs 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. After each CHECKIN, a new VR is created, and edited VCR's contents now point to the latest VR. Each VCR has also has a history resource which tracks and orders its various VR states.

Client-side working-copy model

Some DeltaV servers also support the idea that the client may have a private working copy full of specific VRs. (This is how CVS and Subversion work.) 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 VR it wishes to change, which creates a number of temporary working resources in the activity, that can be modified using PUT and PROPPATCH methods. Finally, the client performs a CHECKIN on each working resource, which creates a new VR within each VCR, and the entire activity is deleted.

Configurations

DeltaV allows you define flexible collections of VCRs called configurations, which don't necessarily respond to particular directories. Each VCR's contents can be made to point to a specific VR using the UPDATE method. Once the configuration is perfect, the client can create a snapshot of the whole configuration, called a baseline. Clients use the CHECKOUT and CHECKIN methods to capture specific states of configurations, much like they use these methods to create specific VR states of VCRs.

Extensibility

DeltaV defines a new method, REPORT, which allows the client and server to perform customized data exchanges. 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.

Autoversioning

For many, this is the killer feature of DeltaV. If the DeltaV server supports this feature, then basic WebDAV clients (i.e., those unaware of versioning) can still write to the server, and the server will silently perform versioning anyway. In the simplest example, an ignorant PUT from a basic WebDAV client might be translated by the server as a CHECKOUT, PUT, CHECKIN.