WebDAV and Collaborative Authoring

19.2 WebDAV and Collaborative Authoring

Web Distributed Authoring and Versioning (WebDAV) adds an extra dimension to web publishingcollaboration. Currently, the most common practice of collaboration is decidedly low-tech: predominantly email, sometimes combined with distributed fileshares. This practice has proven to be very inconvenient and error-prone , with little or no control over the process. Consider an example of launching a multinational, multilingual web site for an automobile manufacturer. Its easy to see the need for a robust system with secure, reliable publishing primitives, along with collaboration primitives such as locking and versioning.

WebDAV (published as RFC 2518) is focused on extending HTTP to provide a suitable platform for collaborative authoring. It currently is an IETF effort with support from various vendors , including Adobe, Apple, IBM, Microsoft, Netscape, Novell, Oracle, and Xerox.

19.2.1 WebDAV Methods

WebDAV defines a set of new HTTP methods and modifies the operational scope of a few other HTTP methods. The new methods added by WebDAV are:

PROPFIND

Retrieves the properties of a resource.

PROPPATCH

Sets one or more properties on one or many resources.

MKCOL

Creates collections.

COPY

Copies a resource or a collection of resources from a given source to a given destination. The destination need not be on the same machine.

MOVE

Moves a resource or a collection of resources from a given source to a given destination. The destination need not be on the same machine.

LOCK

Locks a resource or multiple resources.

UNLOCK

Unlocks a previously locked resource.

HTTP methods modified by WebDAV are DELETE, PUT, and OPTIONS. Both the new and the modified methods are discussed in detail later in this chapter.

19.2.2 WebDAV and XML

WebDAV's methods generally require a great deal of information to be associated with both requests and responses. HTTP usually communicates this information in message headers. However, transporting necessary information in headers alone imposes some limitations, including the difficulties of selective application of header information to multiple resources in a request, to represent hierarchy, etc.

To solve this problem, WebDAV embraces the Extensible Markup Language (XML), a meta-markup language that provides a format for describing structured data. XML provides WebDAV with:

                A method of formatting instructions describing how data is to be handled

                A method of formatting complex responses from the server

                A method of communicating customized information about the collections and resources handled

                A flexible vehicle for the data itself

                A robust solution for most of the internationalization issues

Traditionally, the schema definition for XML documents is kept in a Document Type Definition (DTD) file that is referenced within the XML document itself. Therefore, when trying to interpret an XML document, the DOCTYPE definition entity gives the name of the DTD file associated with the XML document in question.

WebDAV defines an explicit XML namespace, "DAV:". Without going into many details, an XML namespace is a collection of names of elements or attributes. The namespace qualifies the embedded names unique across the domain, thus avoiding any name collisions.

The complete XML schema is defined in the WebDAV specification, RFC 2518. The presence of a predefined schema allows the parsing software to make assumptions on the XML schema without having to read in DTD files and interpret them correctly.

19.2.3 WebDAV Headers

WebDAV does introduce several HTTP headers to augment the functionality of the new methods. This section provides a brief overview; see RFC 2518 for more information. The new headers are:

DAV

Used to communicate the WebDAV capabilities of the server. All resources supported by WebDAV are required to return this header in the response to the OPTIONS request. See Section 19.2.14.2 for more details.

 DAV = "DAV" ":" "1" ["," "2"] ["," 1#extend] 

Depth

The crucial element for extending WebDAV to grouped resources with multiple levels of hierarchy (for more detailed explanation about collections, please refer to Section 19.2.10 ).

 Depth = "Depth" ":" ("0"  "1"  "infinity") 

Let's look at a simple example. Consider a directory DIR_A with files file_1.html and file_2.html . If a method uses Depth: 0, the method applies to the DIR_A directory alone, and Depth: 1 applies to the DIR_A directory and its files, file_1.html and file_2.html .

The Depth header modifies many WebDAV-defined methods. Some of the methods that use the Depth header are LOCK, COPY, and MOVE.

Destination

Defined to assist the COPY or MOVE methods in identifying the destination URI.

 Destination = "Destination" ":" absoluteURI 

If

The only defined state token is a lock token (see Section 19.2.5 ). The If header defines a set of conditionals; if they all evaluate to false, the request will fail. Methods such as COPY and PUT conditionalize the applicability by specifying preconditions in the If header. In practice, the most common precondition to be satisfied is the prior acquisition of a lock.

 If = "If" ":" (1*No-tag-list  1*Tagged-list) 

 No-tag-list = List 

 Tagged-list = Resource 1*List 

 Resource = Coded-URL 

 List = "(" 1*(["Not"](State-token  "[" entity-tag "]")) ")" 

 State-token = Coded-URL 

 Coded-URL = "<" absoluteURI ">" 

Lock-Token

Used by the UNLOCK method to specify the lock that needs to be removed. A response to a LOCK method also has a Lock-Token header, carrying the necessary information about the lock taken.

 Lock-Token = "Lock-Token" ":" Coded-URL 

Overwrite

Used by the COPY and MOVE methods to designate whether the destination should be overwritten. See the discussion of the COPY and MOVE methods later in this chapter for more details.

 Overwrite = "Overwrite" ":" ("T"  "F") 

Timeout

A request header used by a client to specify a desired lock timeout value. For more information, refer to Section 19.2.5.3 .

 TimeOut = "Timeout" ":" 1#TimeType 

 TimeType = ("Second-" DAVTimeOutVal  "Infinite"  Other) 

 DAVTimeOutVal = 1*digit 

 Other = "Extend" field-value 

Now that we have sketched the intent and implementation of WebDAV, let's look more closely at the functions provided.

19.2.4 WebDAV Locking and Overwrite Prevention

By definition, collaboration requires more than one person working on a given document. The inherent problem associated with collaboration is illustrated in Figure 19-3 .

Figure 19-3. Lost update problem

In this example, authors A and B are jointly writing a specification. A and B independently make a set of changes to the document. A pushes the updated document to the repository, and at a later point, B posts her own version of the document into the repository. Unfortunately, because B never knew about A's changes, she never merged her version with A's version, resulting in A's work being lost.

To ameliorate the problem, WebDAV supports the concept of locking. Locking alone will not fully solve the problem. Versioning and messaging support are needed to complete the solution.

WebDAV supports two types of locks:

                Exclusive write locking of a resource or a collection

                Shared write locking of a resource or a collection

An exclusive write lock guarantees write privileges only to the lock owner. This type of locking completely eliminates potential conflicts. A shared write lock allows a group of people to work on a given document. This type of locking works well in an environment where all the authors are aware of each other's activities. WebDAV provides a property discovery mechanism, via PROPFIND, to determine the support for locking and the types of locks supported.

WebDAV has two new methods to support locking: LOCK and UNLOCK.

To accomplish locking, there needs to be a mechanism for identifying the author. WebDAV requires digest authentication (discussed in Chapter 13 ).

When a lock is granted, the server returns a token that is unique across the domain to the client. The specification refers to this as the opaquelocktoken lock token URI scheme. When the client subsequently wants to perform a write, it connects to the server and completes the digest authentication sequence. Once the authentication is complete, the WebDAV client presents the lock token, along with the PUT request. Thus, the combination of the correct user and the lock token is required to complete the write.

19.2.5 The LOCK Method

A powerful feature of WebDAV is its ability to lock multiple resources with a single LOCK request. WebDAV locking does not require the client to stay connected to the server.

For example, here's a simple LOCK request:

 LOCK /ch-publish.fm HTTP/1.1 

 Host: minstar 

 Content-Type: text/xml 

 User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT) 

 Content-Length: 201 

 <?xml version="1.0"?> 

 <a:lockinfo xmlns:a="DAV:"> 

 <a:lockscope><a:exclusive/></a:lockscope> 

 <a:locktype><a:write/></a:locktype> 

 <a:owner><a:href>AuthorA</a:href></a:owner> 

 </a:lockinfo> 

The XML being submitted has the <lockinfo> element as its base element. Within the <lockinfo> structure, there are three subelements:

<locktype>

Indicates the type of lock. Currently there is only one, "write."

<lockscope>

Indicates whether this is an exclusive lock or a shared lock.

<owner>

Field is set with the person who holds the current lock.

Here's a successful response to our LOCK request:

 HTTP/1.1 200 OK 

 Server: Microsoft-IIS/5.0 

 Date: Fri, 10 May 2002 20:56:18 GMT 

 Content-Type: text/xml 

 Content-Length: 419 

 <?xml version="1.0"?> 

 <a:prop xmlns:a="DAV:"> 

 <a:lockdiscovery><a:activelock> 

 <a:locktype><a:write/></a:locktype> 

 <a:lockscope><a:exclusive/></a:lockscope> 

 <a:owner xmlns:a="DAV:"><a:href>AutherA</a:href></a:owner> 

 <a:locktoken><a:href>opaquelocktoken:*****</a:href></a:locktoken> 

 <a:depth>0</a:depth> 

 <a:timeout>Second-180</a:timeout> 

 </a:activelock></a:lockdiscovery> 

 </a:prop> 

The <lockdiscovery> element acts as a container for information about the lock. Embedded in the <lockdiscovery> element is an <activelock> subelement that holds the information sent with the request (<locktype>, <lockscope>, and <owner>). In addition, <activelock> has the following subelements:

<locktoken>

Uniquely identifies the lock in a URI scheme called opaquelocktoken . Given the stateless nature of HTTP, this token is used to identify the ownership of the lock in future requests.

<depth>

Mirrors the value of the Depth header.

<timeout>

Indicates the timeout associated with the lock. In the above response ( Figure 19-3 ), the timeout value is 180 seconds.

19.2.5.1 The opaquelocktoken scheme

The opaquelocktoken scheme is designed to provide a unique token across all resources for all times. To guarantee uniqueness, the WebDAV specification mandates the use of the universal unique identifier (UUID) mechanism, as described in ISO-11578.

When it comes to actual implementation, there is some leeway. The server has the choice of generating a UUID for each LOCK request, or generating a single UUID and maintaining the uniqueness by appending extra characters at the end. For performance considerations, the latter choice is better. However, if the server chooses to implement the latter choice, it is required to guarantee that none of the added extensions will ever be reused.

19.2.5.2 The <lockdiscovery> XML element

The <lockdiscovery> XML element provides a mechanism for active lock discovery. If others try to lock the file while a lock is in place, they will receive a <lockdiscovery> XML element that indicates the current owner. The <lockdiscovery> element lists all outstanding locks along with their properties.

19.2.5.3 Lock refreshes and the Timeout header

To refresh a lock, a client needs to resubmit a lock request with the lock token in the If header. The timeout value returned may be different from the earlier timeout values.

Instead of accepting the timeout value given by the server, a client may indicate the timeout value required in the LOCK request. This is done through the Timeout header. The syntax of the Timeout header allows the client to specify a few options in a comma-separated list. For example:

 Timeout : Infinite, Second-86400 

The server is not obligated to honor either of the options. However, it is required to provide the lock expiration time in the <timeout> XML element. In all cases, lock timeout is only a guideline and is not necessarily binding on the server. The administrator may do a manual reset, or some other extraordinary event may cause the server to reset the lock. The clients should avoid taking lengthy locks.

In spite of these primitives, we may not completely solve the "lost update problem" illustrated in Figure 19-3 . To completely solve it, a cooperative event system with a versioning control is needed.

19.2.6 The UNLOCK Method

The UNLOCK method removes a lock on a resource, as follows :

 UNLOCK /ch-publish.fm HTTP/1.1 

 Host: minstar.inktomi.com 

 User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT) 

 Lock-Token: 

 opaquelocktoken:********* 

 HTTP/1.1 204 OK 

 Server: Microsoft-IIS/5.0 

 Date: Fri, 10 May 2002 20:56:18 GMT 

As with most resource management requests, WebDAV has two requirements for UNLOCK to succeed: prior completion of a successful digest authentication sequence, and matching the lock token that is sent in the Lock-Token header.

If the unlock is successful, a 204 No Content status code is returned to client. Table 19-1 summarizes the possible status codes with the LOCK and UNLOCK methods.

Table 19-1. Status codes for LOCK and UNLOCK methods
Status code	Defined by	Method	Effect
200 OK	HTTP	LOCK	Indicates successful locking.
201 Created	HTTP	LOCK	Indicates that a lock on a nonexistent resource succeeded by creating the resource.
204 No Content	HTTP	UNLOCK	Indicates successful unlocking.
207 Multi-Status	WebDAV	LOCK	The request was for locking multiple resources. Not all status codes returned were the same. Hence, they are all encapsulated in a 207 response.
403 Forbidden	HTTP	LOCK	Indicates that the client does not have permission to lock the resource.
412 Precondition Failed	HTTP	LOCK	Either the XML sent with the LOCK command indicated a condition to be satisfied and the server failed to complete the required condition, or the lock token could not be enforced.
422 Unprocessable Property	WebDAV	LOCK	Inapplicable semanticsan example may be specifying a nonzero Depth for a resource that is not a collection.
423 Locked	WebDAV	LOCK	Already locked.
424 Failed Dependency	WebDAV	UNLOCK	UNLOCK specifies other actions and their success as a condition for the unlocking. This error is returned if the dependency fails to complete.

19.2.7 Properties and META Data

Properties describe information about the resource, including the author's name, modification date, content rating, etc. META tags in HTML do provide a mechanism to embed this information as part of the content; however, many resources (such as any binary data) have no capability for embedding META data.

A distributed collaborative system such as WebDAV adds more complexity to the property requirement. For example, consider an author property: when a document gets edited, this property needs to be updated to reflect the new authors. WebDAV terms such dynamically modifiable properties "live" properties. The more permanent, static properties, such as Content-Type, are termed "dead" properties.

To support discovery and modification of properties, WebDAV extends HTTP to include two new methods, PROPFIND and PROPPATCH. Examples and corresponding XML elements are described in the following sections.

19.2.8 The PROPFIND Method

The PROPFIND (property find) method is used for retrieving the properties of a given file or a group of files (also known as a "collection"). PROPFIND supports three types of operations:

                Request all properties and their values.

                Request a selected set of properties and values.

                Request all property names.

Here's the scenario where all the properties and their values are requested :

 PROPFIND /ch-publish.fm HTTP/1.1 

 Host: minstar.inktomi.com 

 User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT) 

 Depth: 0 

 Cache-Control: no-cache 

 Connection: Keep-Alive 

 Content-Length: 0 

The <propfind> request element specifies the properties to be returned from a PROPFIND method. The following list summarizes a few XML elements that are used with PROPFIND requests:

<allprop>

Requires all property names and values to be returned. To request all properties and their values, a WebDAV client may either send an <allprop> XML subelement as part of the <propfind> element, or submit a request with no body.

<propname>

Specifies the set of property names to be returned.

<prop>

A subelement of the <propfind> element. Specifies a specific property whose value is to be returned. For example: "<a:prop> <a:owner />..... </a:prop>".

Here's a response to a sample PROPFIND request:

 HTTP/1.1 207 Multi-Status 

 Server: Microsoft-IIS/5.0 

 ........... 

 <?xml version="1.0"?> 

 <a:multistatusxmlns:b="urn:uuid:********/" xmlns:c="xml:" xmlns:a="DAV:"> 

 <a:response> 

 <a:href>http://minstar/ch-publish.fm </a:href> 

 <a:propstat> 

 <a:status>HTTP/1.1 200OK</a:status> 

 <a:prop> 

 <a:getcontentlength b:dt="int">1155</a:getcontentlength> 

 ...................... 

 ...................... 

 <a:ishidden b:dt="boolean">0</a:ishidden> 

 <a:iscollection b:dt="boolean">0</a:iscollection> 

 </a:prop> 

 </a:propstat> 

 </a:response></a:multistatus> 

In this example, the server responds with a 207 Multi-Status code. WebDAV uses the 207 response for PROPFIND and a few other WebDAV methods that act simultaneously on multiple resources and potentially have different responses for each resource.

A few XML elements in the response need to be defined:

<multistatus>

A container for multiple responses.

<href>

Identifies the resource's URI.

<status>

Contains the HTTP status code for the particular request.

<propstat>

Groups one <status> element and one <prop> element. The <prop> element may contain one or more property name/value pairs for the given resource.

In the sample response listed above, the response is for one URI, http://minstar/ch-publish.fm . The <propstat> element embeds one <status> element and one <prop> element. For this URI, the server returned a 200 OK response, as defined by the <status> element. The <prop> element has several subelements; only some are listed in the example.

One instant application of PROPFIND is the support for directory listing. Given the expressability of a PROPFIND request, one single call can retrieve the entire hierarchy of the collection with all the properties of individual entities.

19.2.9 The PROPPATCH Method

The PROPPATCH method provides an atomic mechanism to set or remove multiple properties on a given resource. The atomicity will guarantee that either all of the requests are successful or none of them made it.

The base XML element for the PROPPATCH method is <propertyupdate>. It acts as a container for all the properties that need updating. The XML elements <set> and <remove> are used to specify the operation:

<set>

Specifies the property values to be set. The <set> contains one or more <prop> subelements, which in turn contains the name/value pairs of the properties to be set for the resource. If the property already exists, the value is replaced .

<remove>

Specifies the properties that are to be removed. Unlike with <set>, only the names of the properties are listed in the <prop> container.

This trivial example sets and removes the "owner" property:

 <d:propertyupdate xmlns:d="DAV:" xmlns:o="http://name-space/scheme/"> 

 <d:set> 

 <d:prop> 

 <o:owner>Author A</o:owner> 

 </d:prop> 

 </d:set> 

 <d:remove> 

 <d:prop> 

 <o:owner/> 

 </d:prop> 

 </d:remove> 

 </d:propertyupdate> 

The response to PROPPATCH requests is very similar to that for PROPFIND requests. For more information, refer to RFC 2518.

Table 19-2 summarizes the status codes for the PROPFIND and PROPPATCH methods.

Table 19-2. Status codes for PROPFIND and PROPPATCH methods
Status code	Defined by	Methods	Effect
200 OK	HTTP	PROPFIND, PROPPATCH	Command success.
207 Multi-Status	WEBDAV	PROPFIND, PROPPATCH	When acting on one or more resources (or a collection), the status for each object is encapsulated into one 207 response. This is a typical success response.
401 Unauthorized	HTTP	PROPATCH	Requires authorization to complete the property modification operation.
403 Forbidden	HTTP	PROPFIND, PROPPATCH	For PROPFIND, the client is not allowed to access the property. For PROPPATCH, the client may not change the property.
404 Not Found	HTTP	PROPFIND	No such property.
409 Conflict	HTTP	PROPPATCH	Conflict of update semanticsfor example, trying to update a read-only property.
423 Locked	WebDAV	PROPPATCH	Destination resource is locked and there is no lock token or the lock token does not match.
507 Insufficient Storage	WebDAV	PROPPATCH	Not enough space for registering the modified property.

19.2.10 Collections and Namespace Management

A collection refers to a logical or physical grouping of resources in a predefined hierachy. A classic example of a collection is a directory. Like directories in a filesystem, collections act as containers of other resources, including other collections (equivalent to directories on the filesystem).

WebDAV uses the XML namespace mechanism. Unlike traditional namespaces, XML namespace partitions allow for precise structural control while preventing any namespace collisions.

WebDAV provides five methods for manipulating the namespace: DELETE, MKCOL, COPY, MOVE, and PROPFIND. PROPFIND was discussed previously in this chapter, but let's talk about the other methods.

19.2.11 The MKCOL Method

The MKCOL method allows clients to create a collection at the indicated URL on the server. At first sight, it may seem rather redundant to define an entire new method just for creating a collection. Overlaying on top of a PUT or POST method seems like a perfect alternative. The designers of the WebDAV protocol did consider these alternatives and still chose to define a new method. Some of the reasons behind that decision are:

                To have a PUT or a POST create a collection, the client needs to send some extra "semantic glue" along with the request. While this certainly is feasible , defining an ad hoc protocol may become tedious and error-prone.

                Most of the access-control mechanisms are based on the type of methodsonly a few are allowed to create and delete resources in the repository. If we overload other methods, these access-control mechanisms will not work.

For example, a request might be:

 MKCOL /publishing HTTP/1.1 

 Host: minstar 

 Content-Length: 0 

 Connection: Keep-Alive 

And the response might be:

 HTTP/1.1 201 Created 

 Server: Microsoft-IIS/5.0 

 Date: Fri, 10 May 2002 23:20:36 GMT 

 Location: http://minstar/publishing/ 

 Content-Length: 0 

Let us examine a few pathological cases:

                Suppose the collection already exists. If a MKCOL /colA request is made and colA already exists (i.e., namespace conflict), the request will fail with a 405 Method Not Allowed status code.

                If there are no write permissions, the MKCOL request will fail with a 403 Forbidden status code.

                If a request such as MKCOL /colA/colB is made and colA does not exist, the request will fail with a 409 Conflict status code.

Once the file or collection is created, we can delete it with the DELETE method.

19.2.12 The DELETE Method

We already saw the DELETE method in Chapter 3 . WebDAV extends the semantics to cover collections.

If we need to delete a directory, the Depth header is needed. If the Depth header is not specified, the DELETE method assumes the Depth header to be set to infinitythat is, all the files in the directory and any subdirectories thereof are deleted. The response also has a Content-Location header identifying the collection that just got deleted. The request might read:

 DELETE /publishing HTTP/1.0 

 Host: minstar 

And the response might read:

 HTTP/1.1 200 OK 

 Server: Microsoft-IIS/5.0 

 Date: Tue, 14 May 2002 16:41:44 GMT 

 Content-Location: http://minstar/publishing/ 

 Content-Type: text/xml 

 Content-Length: 0 

When removing collections, there always is a chance that a file in the collection is locked by someone else and can't be deleted. In such a case, the collection itself can't be deleted, and the server replies with a 207 Multi-Status status code. The request might read:

 DELETE /publishing HTTP/1.0 

 Host: minstar 

And the response might read:

 HTTP/1.1 207 Multi-Status 

 Server: Microsoft-IIS/5.0 

 Content-Location: http://minstar/publishing/ 

 .............. 

 <?xml version="1.0"?> 

 <a:multistatus xmlns:a="DAV:"> 

 <a:response> 

 <a:href>http://minstar/index3/ch-publish.fm</a:href> 

 <a:status> HTTP/1.1 423 Locked </a:status> 

 </a:response> 

 </a:multistatus> 

In this transaction, the <status> XML element contains the status code 403 Locked, indicating that the resource ch-publish.fm is locked by another user.

19.2.13 The COPY and MOVE Methods

As with MKCOL, there are alternatives to defining new methods for COPY and MOVE operations. One such alternative for the COPY method is to do a GET request on the source, thus downloading the resource, and then to upload it back to the server with a PUT request. A similar scenario could be envisioned for MOVE (with the additional DELETE operation). However, this process does not scale wellconsider all the issues involved in managing a COPY or MOVE operation on a multilevel collection.

Both the COPY and MOVE methods use the request URL as the source and the contents of the Destination HTTP header as the target. The MOVE method performs some additional work beyond that of the COPY method: it copies the source URL to the destination, checks the integrity of the newly created URI, and then deletes the source. The request might read:

 {COPY,MOVE} /publishing HTTP/1.1 

 Destination: http://minstar/pub-new 

 Depth: infinity 

 Overwrite: T 

 Host: minstar 

And the response might read:

 HTTP/1.1 201 Created 

 Server: Microsoft-IIS/5.0 

 Date: Wed, 15 May 2002 18:29:53 GMT 

 Location: http://minstar.inktomi.com/pub-new/ 

 Content-Type: text/xml 

 Content-Length: 0 

When acting on a collection, the behavior of COPY or MOVE is affected by the Depth header. In the absence of the Depth header, infinity is assumed (i.e., by default, the entire structure of the source directory will be copied or moved). If the Depth is set to zero, the method is applied just to the resource. If we are doing a copy or a move of a collection, only a collection with properties identical to those of the source is created at the destinationno internal members of the collection are copied or moved.

For obvious reasons, only a Depth value of infinity is allowed with the MOVE method.

19.2.13.1 Overwrite header effect

The COPY and MOVE methods also may use the Overwrite header. The Overwrite header can be set to either T or F . If it's set to T and the destination exists, a DELETE with a Depth value of infinity is performed on the destination resource before a COPY or MOVE operation. If the Overwrite flag is set to F and the destination resource exists, the operation will fail.

19.2.13.2 COPY/MOVE of properties

When a collection or an element is copied, all of its properties are copied by default. However, a request may contain an optional XML body that supplies additional information for the operation. You can specify that all properties must be copied successfully for the operation to succeed, or define which properties must be copied for the operation to succeed.

A couple of pathological cases to consider are:

                Suppose COPY or MOVE is applied to the output of a CGI program or other script that generates content. To preserve the semantics, if a file generated by a CGI script is to be copied or moved, WebDAV provides "src" and "link" XML elements that point to the location of the program that generated the page.

                The COPY and MOVE methods may not be able to completely duplicate all of the live properties. For example, consider a CGI program. If it is copied away from the cgi-bin directory, it may no longer be executed. The current specification of WebDAV makes COPY and MOVE a "best effort" solution, copying all the static properties and the appropriate live properties.

19.2.13.3 Locked resources and COPY/MOVE

If a resource currently is locked, both COPY and MOVE are prohibited from moving or duplicating the lock at the destination. In both cases, if the destination is to be created under an existing collection with its own lock, the duplicated or moved resource is added to the lock. Consider the following example:

 COPY /publishing HTTP/1.1 

 Destination: http://minstar/archived/publishing-old 

Let's assume that /publishing and /archived already are under two different locks, lock1 and lock2. When the COPY operation completes, /publishing continues to be under the scope of lock1, while, by virtue of moving into a collection that's already locked by lock2, publishing-old gets added to lock2. If the operation was a MOVE, just publishing-old gets added to lock2.

Table 19-3 lists most of the possible status codes for the MKCOL, DELETE, COPY, and MOVE methods.

Table 19-3. Status codes for the MKCOL, DELETE, COPY, and MOVE methods
Status code	Defined by	Methods	Effect
102 Processing	WebDAV	MOVE, COPY	If the request takes longer than 20 seconds, the server sends this status code to keep clients from timing out. This usually is seen with a COPY or MOVE of a large collection.
201 Created	HTTP	MKCOL, COPY, MOVE	For MKCOL, a collection has been created. For COPY and MOVE, a resource/collection was copied or moved successfully.
204 No Content	HTTP	DELETE, COPY, MOVE	For DELETE, a standard success response. For COPY and MOVE, the resource was copied over successfully or moved to replace an existing entity.
207 Multi-Status	WebDAV	MKCOL, COPY, MOVE	For MKCOL, a typical success response. For COPY and MOVE, if an error is associated with a resource other than the request URI, the server returns a 207 response with the XML body detailing the error.
403 Forbidden	HTTP	MKCOL, COPY, MOVE	For MKCOL, the server does not allow creation of a collection at the specified location. For COPY and MOVE, the source and destination are the same.
409 Conflict	HTTP	MKCOL, COPY, MOVE	In all cases, the methods are trying to create a collection or a resource when an intermediate collection does not existfor example, trying to create colA/colB when colA does not exist.
412 Precondition Failed	HTTP	COPY, MOVE	Either the Overwrite header is set to F and the destination exists, or the XML body specifies a certain requirement (such as keeping the "liveness" property) and the COPY or MOVE methods are not able to retain the property.
415 Unsupported Media Type	HTTP	MKCOL	The server does not support or understand the creation of the request entity type.
422 Unprocessable Entity	WebDAV	MKCOL	The server does not understand the XML body sent with the request.
423 Locked	WebDAV	DELETE, COPY, MOVE	The source or the destination resource is locked, or the lock token supplied with the method does not match.
502 Bad Gateway	HTTP	COPY, MOVE	The destination is on a different server and permissions are missing.
507 Insufficient Storage	WebDAV	MKCOL COPY	There is not enough free space to create the resource.

19.2.14 Enhanced HTTP/1.1 Methods

WebDAV modifies the semantics of the HTTP methods DELETE, PUT, and OPTIONS. Semantics for the GET and HEAD methods remain unchanged. Operations performed by POST always are defined by the specific server implementation, and WebDAV does not modify any of the POST semantics. We already covered the DELETE method, in Section 19.2.10 . We'll discuss the PUT and OPTIONS methods here.

19.2.14.1 The PUT method

Though PUT is not defined by WebDAV, it is the only way for an author to transport the content to a shared site. We discussed the general functionality of PUT in Chapter 3 . WebDAV modifies its behavior to support locking.

Consider the following example:

 PUT /ch-publish.fm HTTP/1.1 

 Accept: */* 

 If:<http://minstar/index.htm>(<opaquelocktoken:********>) 

 User-Agent: DAV Client (C) 

 Host: minstar.inktomi.com 

 Connection: Keep-Alive 

 Cache-Control: no-cache 

 Content-Length: 1155 

To support locking, WebDAV adds an If header to the PUT request. In the above transaction, the semantics of the If header state that if the lock token specified with the If header matches the lock on the resource (in this case, ch-publish.fm ), the PUT operation should be performed. The If header also is used with a few other methods, such as PROPPATCH, DELETE, MOVE, LOCK, UNLOCK, etc.

19.2.14.2 The OPTIONS method

We discussed OPTIONS in Chapter 3 . This usually is the first request a WebDAV-enabled client makes. Using the OPTIONS method, the client tries to establish the capability of the WebDAV server. Consider a transaction in which the request reads:

 OPTIONS /ch-publish.fm HTTP/1.1 

 Accept: */* 

 Host: minstar.inktomi.com 

And the response reads:

 HTTP/1.1 200 OK 

 Server: Microsoft-IIS/5.0 

 MS-Author-Via: DAV 

 DASL: <DAV:sql> 

 DAV: 1, 2 

 Public: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, POST, COPY, MOVE, MKCOL,PROPFIND, 

 PROPPATCH, LOCK, UNLOCK, SEARCH 

 Allow: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, COPY, MOVE, PROPFIND,PROPPATCH, 

 SEARCH, LOCK, UNLOCK 

There are several interesting headers in the response to the OPTIONS method. A slightly out-of-order examination follows:

                The DAV header carries the information about DAV compliance classes. There are two classes of compliance:

Class 1 compliance

Requires the server to comply with all MUST requirements in all sections of RFC 2518. If the resource complies only at the Class 1 level, it will send 1 with the DAV header.

Class 2 compliance

Meets all the Class 1 requirements and adds support for the LOCK method. Along with LOCK, Class 2 compliance requires support for the Timeout and Lock-Token headers and the <supportedlock> and <lockdiscovery> XML elements. A value of 2 in the DAV header indicates Class 2 compliance.

In the above example, the DAV header indicates both Class 1 and Class 2 compliance.

                The Public header lists all methods supported by this particular server.

                The Allow header usually contains a subset of the Public header methods. It lists only those methods that are allowed on this particular resource ( ch-publish.fm ).

                The DASL header provides the type of query grammar used in the SEARCH method. In this case, it is sql. More details about the DASL header are provided at http://www.webdav.org .

19.2.15 Version Management in WebDAV

It may be ironic, given the "V" in "DAV," but versioning is a feature that did not make the first cut. In a multi-author, collaborative environment, version management is critical. In fact, to completely fix the lost update problem (illustrated in Figure 19-3 ), locking and versioning are essential. Some of the common features associated with versioning are the ability to store and access previous document versions and the ability to manage the change history and any associated annotations detailing the changes.

Versioning was added to WebDAV in RFC 3253.

19.2.16 Future of WebDAV

WebDAV is well supported today. Working implementations of clients include IE 5.x and above, Windows Explorer, and Microsoft Office. On the server side, implementations include IIS5.x and above, Apache with mod_dav, and many others. Both Windows XP and Mac OS 10.x provide support for WebDAV out of the box; thus, any applications written to run on these operating systems are WebDAV-enabled natively.