8.7 Lock Interactions
| It's not always obvious how locks interact with the various operations we've already covered, so now we'll review those operations with a focus on how they must behave in various situations involving locks. Recall that WebDAV does not clearly apply the DELETE method either to the address or to the resource (Section 1.3.2). WebDAV locks apply more consistently to addresses than to resources. Thus, when a collection is locked with depth infinity, it's easier to understand how things work if you assume that the address of the collection is what's really locked, along with all "sub-addresses" or all URLs within the collection's namespace. When a single resource is locked, it's best to assume that it's actually the address that is locked, not the data. Based on this model, most lock behavior makes sense.
However, the model isn't entirely self-consistent. Another important part of the model is that when the data is disassociated from an address, the lock associated with that address disappears:
The final wrinkle in the model is that even though DELETE and MOVE behave as if a lock can't exist on an unmapped URL, RFC2518 defines lock-null resources that are locks on unmapped URLs. The model confusion is likely to be reduced somewhat when WebDAV goes to Draft Standard if lock-null resources are removed from the standard; however, most behavior will generally remain the same. 8.7.1 Adding ResourcesThe methods PUT, MKCOL, COPY, and MOVE all create one or more new resources that didn't exist previously. MOVE is more complicated, so it's addressed in Section 8.7.4. There are only three cases in which a lock can affect the creation of a new resource, and they are mutually exclusive. All cases require the lock token to be used in the request:
In the case of COPY, the source resource could be locked, could be within a locked collection, or could be a collection that contains locked resources. None of these source locks affects the COPY operation whatsoever. Because locks apply to URLs, a source lock is not duplicated when the resource is copied and is not removed during the operation. The source lock token is not required in order to be able to complete a COPY operation, because the source resource is not being modified. WebDAV doesn't allow a lock-null resource to be the destination of a COPY (or MOVE) request. If the client needs to lock a location before copying to it, and no file exists, the client must first LOCK the URL, then apply PUT or MKCOL to the URL to turn the lock-null resource into a regular resource as appropriate, then use the URL as the value of the Destination header in a COPY request to finally put the correct content in place. The PUT method might contain an empty body, in which case the server should create a zero-length resource (see Listing 8-16). Listing 8-16 Example creating a placeholder resource.Create placeholder: PUT /hr/resources/ergonomics/placeholder.txt HTTP/1.1 Host: www.example.com Content-Type: text/plain If-None-Match: * Content-Length: 0 Response: HTTP/1.0 204 No Content Date: Sun, 29 Jul 2001 15:24:17 GMT ETag: "870be-8f0-39ee6a4e" Content-Length: 0 The placeholder resource could also be locked after it is created. Either way, it helps other clients to see what type and name are given to the placeholder, so this might be a good practice in other situations, too. 8.7.2 Modifying Locked ResourcesPUT and PROPPATCH can both be used to modify existing resources. COPY and MOVE can also be used to modify a pre-existing destination resource. Modifying a resource does not affect whether it is locked or unlocked, no matter whether the resource is locked itself, contains a locked resource, or is contained within a locked resource. Of course, the lock tokens must be provided, but the locks themselves are unchanged. 8.7.3 DeletingWhen a resource that is directly locked is deleted, its lock disappears. When an indirectly locked resource (within a collection locked with a depth infinity lock) is deleted, it is simply removed from the lock, but the lock remains in place unchanged. These two cases are mutually exclusive. Since lock-null resources do not support DELETE, there's no interaction to worry about there. Instead, a lock-null resource will disappear when its lock is removed, so UNLOCK will achieve the effect of a DELETE. On servers that do not remove the lock-null resource when it is unlocked, the client must check after the UNLOCK to see if it must be followed by a DELETE to actually get rid of the resource. 8.7.4 MOVE and LocksMoving resource can be complicated because there can be locks at the source and at the destination. The WebDAV designers had to pick one model: keep the source lock, keep the destination lock, or keep neither. They chose to keep the destination lock. COPY also effectively keeps the destination lock, so the two methods are consistent. There are a number of cases to consider for the source lock (the destination lock behaves as it did with COPY):
In all of these cases, all of the lock tokens are required for the MOVE request to succeed. |
A MOVE operation associates a new URL with existing data. If the moved resource was directly locked, its lock is destroyed, and neither the unmapped source URL or the new destination URL are locked. RFC2518 specifically requires this behavior even though it makes rename operations behave unexpectedly for users. Client software could attempt to get a new lock immediately if this makes most sense to their users, or it could even go to more work to lock the destination and then MOVE the source over it, preserving the destination lock.
EAN: N/A
Pages: 146