| The UNLOCK request is used to release a lock so that the resources locked may be modified or locked by other users. The syntax is simple (see Listing 8-4).  | Note that the lock token must be provided for the server to know which lock to remove, because there may be more than one on a resource. Also note that the user sends his or her authorization. The server should only allow the lock creator to remove a lock, even though the lock token was provided. Typically, only the user for whom the lock was created can remove the lock, but some servers allow specially privileged users, such as the resource owner, to remove any lock. |
Listing 8-4 UNLOCK request and response. UNLOCK /hr/ergonomics/posture.doc HTTP/1.1 Host: www.example.com Lock-Token: <opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6> Authorization: Basic dGVzdHVzZXI6dGVzdHVzZXI=  Response: HTTP/1.1 204 No Content Date: Sun, 29 Jul 2001 15:24:17 GMT Clients should release locks when they're no longer being used. Otherwise, stale locks prevent other authorized users from making their own edits. 8.3.1 Removing Another User's Lock Under certain circumstances, client software may find it desirable to use the lockdiscovery property to discover the lock token and try to remove the lock, even if the lock was originally taken out by some other client process on the same machine or another user. Provided the server supports this, it can be done in a responsible manner by the client: Client may choose not to offer or allow this operation unless the lock was created by the same user who is currently logged in. Client should warn the user. "Are you sure you want to remove this lock ... " Client must only use the discovered lock token to do an UNLOCK, even if the server allows the lock token to be used with any method. Then, if necessary, the client can create a new lock for its own write operations. If this is done properly, then when the holder of the original locktoken tries to update the file, that client will be informed that the original lock disappeared and so knows that changes may have been made. An automated client should not remove locks that it didn't create. A consistent string in the lock owner string could help the automated client determine which locks it created.
DAV Explorer and Goliath are two WebDAV clients that are known to allow the user to grab the lock token and do away with the lock, even if the lock was created by another user or process.  | The server also has an important role in allowing locks to be used and removed in a responsible manner. The server should only allow the lock token to be used by the same authorized user who created the lock, except potentially when a user with a high level of permissions needs to destroy the lock. Still, even users with high levels of permissions should not be allowed to alter a resource using a lock taken out by a different authorized user, because the client software that took out the lock originally will have no way of detecting that its lock has been used to make modifications. Instead, if the lock is deleted, the client that originally took out the lock will know as soon as it tries to use the lock (perform a write operation, renew, or unlock) that it is no longer valid and it must begin again. |
8.3.2 Special Response Codes for UNLOCK A successful response to UNLOCK is 204 No Content because the response message has no body. The most common failure status codes are: 401 Unauthorized: If the client isn't authorized to unlock the resource (it's somebody else's lock). 400 Bad Request: If the client does not provide a lock token. 412 Precondition Failed: If the client provides a lock token to unlock a resource that isn't locked or provides an incorrect lock token.
|
