8.8 Problems with Lock-Null Resources

Lock-null resources are created when a client sends a LOCK request to a resource that does not exist. Lock-null resources behave differently from locked resources in a few specified ways. These special resources bring a number of complications and problems.

8.8.1 Poor Implementation Support

The WebDAV Interop event in the summer of 2001 made it clear that very few servers fully implement the specification for lock-null resources. Only Xythos WebFile Server supported all required lock-null behaviors. Most servers, like WebSite Director and Microsoft IIS 5, supported locking null resources, but they created an empty normal resource, which cannot be turned into a collection and which does not disappear when unlocked.

What are the reasons for this poor support? Sometimes it's due to existing architecture limitations. Microsoft IIS 5.0 could not easily support lock-null resources, because it was built to use the file system to store resources, and that architecture was extended only minimally and carefully to support WebDAV. NTFS supports regular file locks, so individual file locking via WebDAV could be supported consistently. However, NTFS has neither collection locks nor null locks, so it was impossible to safely and quickly implement these features. Any NTFS-based client working on the same files would either override the lock or see incompatible server behavior. The first choice would mean collection and null locks would be insecure, and the second choice would mean that NTFS clients would no longer interoperate reliably with an NTFS server. Neither of those choices was acceptable, so Microsoft chose not to support collection locks or lock-null resources as specified and to leave IIS 5.0 noncompliant.

Some clients (such as the Adobe clients) require the ability to LOCK a nonexistent resource and then PUT to it. IIS 5.0 interoperates with these clients because IIS 5.0 handles a LOCK to an unmapped URL by creating a regular empty resource and locking it. It's an empty locked resource, not a special lock-null resource, but it works for PUT (just not for MKCOL). Unlike lock-null resources, the empty locked resources show up in PROPFIND responses, and they do not disappear when moved. Other server implementors can currently get away with the same shortcut and still interoperate successfully with known clients, and it may even become the standard behavior when WebDAV is updated.

8.8.2 Lock-Null Resources Behave Poorly in Name Collisions

A lock-null resource could be created with a given name and still be a lock-null resource at the time when another client attempts to create a resource with the same name. The second client to attempt to create the resource might try to do this a number of ways.

First, some simplistic clients (MS IE is one example) attempt to see a collection's contents or do a HEAD request to see if a resource exists before attempting to create it. These clients won't see the lock-null resource, yet the PUT request will fail because the client wouldn't provide a lock token.

Second, HTTP or WebDAV clients could send a PUT request with the If-None-Match: * header to make sure that no entity tag matches the requested resource that is to say, it doesn't exist. WebDAV doesn't specify how a lock-null resource matches an ETag or the * syntax. One could imagine this conditional header either failing or succeeding. One way or another, the PUT will not succeed, because the client sending the PUT was unaware of the lock-null resource and of course won't provide a lock token. Still, the client might be confused to see a 423 Locked response and be unable to find any locked resources or confused to see a 412 Preconditions Failed response and not be able to tell why.

Third, WebDAV clients could attempt to LOCK an unmapped URL to create a lock-null resource, not knowing it already is a lock-null resource. Again, the LOCK request wouldn't have the correct lock token, so even though the server will treat it as a renew request, it will fail.

8.8.3 Detecting Lock-Null Resource Creation

A client must be able to tell the difference between the creation of a lock-null resource and the creation of a lock on an existing resource. The distinction is important because the client might be under the impression that it is locking a normal resource when it issues the LOCK. If the resource previously existed but was simply deleted by another client, the LOCK request would succeed anyway, creating a lock-null resource. The next likely step for the client is to try to GET the body of the resource, but this will fail on a lock-null resource, as required by RFC2518.

The status code in the response to the LOCK request differentiates the results of the request. If the response code is 200 OK, an existing resource was locked. If the response code is 201 Created, a new lock-null resource was created. RFC2518 does not cover this explicitly in the listing of response codes for the LOCK request, so existing servers are probably not very reliable in using the 201 Created code. I recommend using this code whenever a null-resource is created in order to give clients more information in the response. Clients should watch out for an unexpected response of 201 Created and undo the operation if creation of a lock-null resource wasn't expected.

A more reliable technique is for the client to use the If-Match header on every LOCK request. Then the request will only succeed if the resource is still in the state the client expected.

8.8.4 Lock-Null Resources Disappear in Collection Moves

When a collection containing lock-null resources is moved or renamed with the MOVE request, those lock-null resources become unlocked and thus disappear. This is a consequence of the decision that a lock must not be moved from the URL where it was created and that it must disappear when that URL is no longer mapped to a resource. When the locks are removed, the server must clean up the lock-null resources.

8.8.5 Lock-Null Resources May Not Be Destination of a COPY

There doesn't seem to be a reason for this restriction in WebDAV, but it's there in the standard. Clients should therefore not attempt to COPY to a lock-null resource. However, should a server accept this operation anyway, there shouldn't be any real problems.

8.8.6 Solving Too Many Problems

The main purpose of lock-null resources was to avoid the overwrite problem that can occur if two users try to create two resources with the same name, at or near the same time. On top of this basic problem were three concerns the working group tried to address. We'll take each concern separately, explain how the concern affected the design of lock-null resources, and examine the consequences and alternatives.

Overwriting Collections

If the overwrite problem must be considered when creating normal resources, surely it must be considered when creating collection resources as well. This consideration led to the design of lock-null resources such that they can become regular collections with a MKCOL operation.

This concern sounds reasonable, but it is useless. Unlike PUT, MKCOL is only used to create collections, not to change them. MKCOL is only allowed on a resource that did not previously exist. There is no overwrite problem or race condition. If two clients send MKCOL to the same URL at around the same time, the second client always gets an error.

The consequence of trying to solve this nonexistent problem was that a resource created as a result of a LOCK could not be a regular resource. The designers foresaw implementation difficulties transforming a regular resource into a collection and decided that a resource created as a result of a LOCK must be a special kind of resource, neither a collection nor a file-like resource. This motivated the requirements that the special kind of resource not respond to a GET, PROPPATCH, MOVE, and COPY. Unfortunately, this special kind of resource is unnecessarily complex and has been poorly implemented.

Reserving New Collection for Property Updates

Another issue that lock-null resources might successfully address is the need for a new collection to be reserved to the process that created it until the new collection is correctly configured. For example, between the MKCOL and the subsequent LOCK request from Alice, Bob may discover the new collection and change properties, add content, or lock it himself.

If Alice could lock the collection on or before the time it is created, then Alice could configure the collection properly before allowing other changes. For example, Alice could set access control such that Bob's changes won't be allowed.

This is one of the few issues that only lock-null resources successfully address.

Cleaning Up Lock-Null Resources May Be Difficult

Here the concern is that a client that mistakenly or intentionally creates a lock-null resource may not have permission to delete the lock-null resource. The concern is real because some servers may grant write permission without granting delete permission. To deal with this concern, WebDAV requires the server to remove lock-null resources when they become unlocked (if the resource hasn't already been turned into a normal resource through PUT or MKCOL).

The consequence of this requirement is that lock-null resources must be handled differently during an UNLOCK operation, during the expiration of a lock, and when a locked parent collection is moved and that lock disappears. Such special-case code is prone to errors.

There are two reasons that this concern, although real, need not be addressed:

• The cleanup problem isn't addressed in other situations. If a client creates a new resource with PUT or creates a new collection with MKCOL, there is just as much potential the client won't have permission to delete those resources. It seems inconsistent and insufficient to address cleanup in only certain odd cases.

• Clients can easily avoid common causes of the need for cleanup. Most of the cleanup concern seems to be for cases when the client did not intend to create a new resource but did so accidentally. The client can avoid this kind of accident simply by using a conditional header on the LOCK request (as with every method that can create a resource), as shown in Listing 8-17. With a correct conditional header, the request will only work if the resource is still in the state the client believes it is in.

Given that there is a workaround that doesn't involve any special-case code, and given that the cleanup problem is a general problem but not too severe a problem, it doesn't seem reasonable to solve the general problem only in one instance when the solution adds such complication.

Listing 8-17 Using If-Match to avoid accidental resource creation on LOCK.

 LOCK /hr/ergonomics/chairs.doc HTTP/1.1 Host: www.example.com Cache-control: no-cache Pragma: no-cache If: ([valid_etag_here]) Timeout: Infinite Content-Type: text/xml; charset="utf-8" Content-Length: xxxx  <?xml version="1.0" encoding="utf-8" ?> <D:lockinfo xmlns:D='DAV:'>    <D:lockscope><D:exclusive/></D:lockscope>    <D:locktype><D:write/></D:locktype>    <D:owner>[e-mail]</D:owner> </D:lockinfo> 

8.8.7 A Simpler Approach: Locked Empty Resources

So, will a simpler approach be better overall? Recall that Microsoft IIS 5.0 simply creates an empty locked regular resource and needs no further special logic. Is this approach sufficient? Many participants in the WebDAV Working Group think so. When RFC2518 is changed to become a Draft Standard, the behavior of lock-null resources will probably be simplified.

In the MS IIS 5.0 approach, when a LOCK request is addressed to a nonexistent resource, the server will create a zero-length document of some predefined type (likely application/octet-stream or text/plain). Then all methods can work as they do on regular resources, without special-case logic, and the client can PUT the real content, potentially changing the content type, at leisure.

Although this solution doesn't solve the problem of creating a locked collection, the benefits seem to outweigh the costs, given how poorly and inconsistently null resources have been implemented.