4.5 Locks

In WebDAV, locks are used to prevent users from overwriting each other's changes accidentally. Locks augment HTTP ETags in this sense, although support for ETags is still necessary for clients and servers to behave well when creating or changing resources. ETags can be used to reliably see whether a document has changed since it was downloaded; locks reserve a document so that it can't be changed between the time it was downloaded and the time the changes are uploaded.

Locking is an optional feature for WebDAV servers. A server may not support locks and would not advertise support for locks. WebDAV clients aren't required to use locks, but a client that is used to make changes to WebDAV resources must be prepared to receive errors when a resource is locked.

WebDAV defines only write locks. Write locks affect write operations, such as PUT, PROPPATCH, MOVE, and COPY. Write locks do not affect read-only requests like GET, thus ordinary Web browsers are unaffected by locks on Web pages. While a resource is locked, any other user (subject to normal permissions) may still download the latest version of the resource.

In Figure 4-6, the lock is represented with a box to show what it encompasses: a resource and the resource properties. Read operations are allowed "through" the lock, and write operations are blocked by the lock, as shown by the prohibited symbols.

Figure 4-6. Locks prevent write operations on that resource only.

Two kinds of write locks may be supported. The common type is an exclusive lock, or one that prevents any other locks on the resource. Servers may also implement shared locks, which can exist together with other shared locks on the same resource (see Section 4.5.10).

Locks have expiration periods, which may be infinite. The user who created the lock may request that it be refreshed. The lock may expire and be removed automatically by the server, or the lock may be removed with an UNLOCK request.

Every lock has a lock token that uniquely identifies the lock. This token is required along with every write request, every lock refresh request, and unlock requests.

4.5.1 Locks and the Lost Update Problem

Locks solve the lost update problem with a minimum of user frustration, as illustrated in Figure 4-7. First, Client A opens the file for editing, issuing a LOCK request to reserve the file. While the file is reserved, Client B tries to open the file for editing as well. When the LOCK request fails immediately, the user can decide to wait until the lock is released before editing the file. The result is that the two users are forced to wait for each other, but their file remains consistent and incorporates both sets of changes.

Figure 4-7. Locks solve the lost update problem by reserving the file.

Some authoring applications give the user an option to open the document "read-only" if a LOCK request fails. In Figure 4-7, Client B could have opened the document to read it initially and later reopened the document to change the salutation. When Word opens a document as read-only, it makes it very difficult for the user to then change the document and overwrite the original resource (Word tries to force the user to save in a different location). This is responsible client behavior in protecting the user from lost updates.

4.5.2 Lock Permissions

Most servers require users to have permission to change a file in order to be allowed to lock it. Otherwise, users who do not have write permission might inadvertently or maliciously lock a file. Even though a write lock is nearly useless to the user without write permission, the lock would still obstruct users who are permitted to make changes.

Windows client behavior provides one example of the reason servers do this. Windows Explorer launches Office whenever possible to read files in the Office file formats. Office 2000 always attempts to lock the files it opens rather than ask the user every time, it makes the assumption that the file must be locked for editing. This is reasonable behavior because Office cannot tell in advance if the user has write permission, so it has no way of knowing if the lock is truly needed. Thus, any time a user navigates to an Office file to view it, the server is asked for a lock. If the server refuses to grant the lock based on lack of write permissions, Office will instead open the file as read-only and everybody gets what they want the user who can read the file gets to read it, and users who can write the file aren't blocked by accidental locks.

4.5.3 Locks and Read Operations

Locks only block write operations (changes to content or properties); locks do not directly affect read operations. This decision allowed locks to be defined simply enough to solve the lost update problem alone, without attempting to solve other access control issues.

When a resource is locked, any user who normally has permission to read the resource can still do so. When a resource is changed, a subsequent read operation returns the latest changes, whether or not the resource is locked.

Ranged read requests are an interesting case. HTTP allows clients to request part of a resource by specifying a range of bytes for the server to return. Since the resource can change (invalidating the older ranges) between one ranged request and the next, HTTP clients always check to make sure the resource hasn't changed (using ETags; see Section 3.4 of Chapter 3). WebDAV seems to offer the ability to lock the file so that the byte ranges can be downloaded without any chance of the resource changing. However, in practice this trick isn't used. Most servers require the user to have write permission before allowing a lock, and it's not worthwhile to the client to try to lock the file (and probably fail due to permissions) just to do ranged read requests.

4.5.4 Locks vs. Access Control

A WebDAV extension [Clemm02] standardizes access control functionality, which includes write permission. Both locks and access control can prevent write operations, but they're used in different ways.

Since locks only cover write operations, a user who has permission to read a resource may read it even when it is locked by another user. Access control changes are needed to grant or remove permission to read a file.

One might imagine replacing locking with a way to revoke write permission; however, in practice this isn't workable. A single lock prevents all other users from writing the resource. In contrast, to prevent writes with access control changes, the client might have to modify several access control entries granting various permissions to several different users or groups. Even if the server had special functions to make revoking and granting write access more automatic, many users don't have permission to change access control settings on the same resources they can author.

Locking was relatively easy to define as a feature of WebDAV, whereas access control is much harder and is taking much longer to standardize. Locking and unlocking a file is much easier than trying to read or write permissions. It's also much easier to define how locks must behave than to define how permissions must behave.

A lock prevents any other user from changing permissions on the locked resource, just like any other change (although this was not formalized until the Access Control specification was published). However, the permission to change access control settings must be governed separately from the permission to write a resource. Many collaboration scenarios involve file administrators (who can change permissions) and file editors (who can change properties and bodies but not permissions). Access control usually provides greater granularity than locks do.

Access control lists are used for persistent control, whereas locks are used for transient control. A file may be locked for only a couple of minutes, and as soon as it's unlocked it's available to be updated by the same users who had write permission before the lock was created. Locks expire, so the server can easily keep the number of locks manageable by keeping timeouts short.

Chapter 13, Access Control, describes WebDAV access control in more detail, including the challenges in defining standard permissions and the granularity of access control entries.

4.5.5 Lock Owners

Locks are used to temporarily prevent write operations by any client that does not provide the lock token. However, as we'll see in Chapter 8, the lock token is a public piece of information, not a secret like a password. Any client can obtain the lock token; lock tokens are discoverable in order to handle clients that lose their lock tokens. However, an unauthorized client could obtain a lock token and attempt to use it. How does the server deal with these attempts?

Only the user that created the lock should be allowed to do write operations, refresh the lock, or remove it. Specifically:

• When a lock is created, the server must store the identity of the user who created the lock.

• When an update (or lock refresh or unlock) request is sent, the server should check both the lock token and the identity of the user.

• If either the lock token or the user identity is missing or different, the server should respond with an error. In the rare cases where a file is publicly writable, the identity of the original lock creator could be unknown, but only in this case should the server accept lock tokens from unknown users.

Note that both the token and the lock owner identity must be known. This double check is required because the lock owner may have more than one piece of WebDAV client software running with the same user identification. For example, the user may be running Office 2000 to edit the documents and at the same time use the sitecopy tool to organize files and collections. By requiring the lock token with any write request, WebDAV ensures that when Office 2000 has a lock on the resource, sitecopy can't move the resource until Office 2000 releases the lock. That's why locks include both lock tokens and owners: It's not enough to know that the authorized principal is accessing the resource, it must also be the right software.

One needn't worry about a loss of security just because lock tokens can be read by anybody. Since lock usage depends on the identity of the lock owner as well as the lock token provided, the lock token itself doesn't need to be a secret. User authentication to check the lock owner identity can be done with carefully designed and time-tested security systems.

4.5.6 Lock Timeout and Lock Refresh

Locks may expire after a designated lifetime, or they may last infinitely long. The ability to expire locks was made part of the standard because client software can leave locks around unwittingly, especially if the client faults or crashes in some manner. These forgotten locks could unnecessarily prevent authorized users from gaining access to change the locked resource, so eventually they are expired. As long as the client software is still active and the user is still updating the file, the client software should be able to continue refreshing the lock.

When creating a lock, the client can request a specific timeout duration, but the server makes the final decision. The server can grant a lock with a timeout either longer or shorter than that requested. When the lock timeout is reached and no refresh request has been received from the lock owner, then the server may remove the lock (and the lock token will be invalid).

The lock owner can refresh the lock any time before the timeout is reached by sending another authenticated LOCK request with the lock token. Client software should do this automatically, based on the timeout granted by the server. Most servers will successfully renew the lock an infinite number of times.

4.5.7 Locks Are Not Transactions

Locks are not transactions, even though they share some similarity. Transactions frequently include rollback and sandboxing functionality, but locks do not.

• Rollback is the ability to undo modifications by canceling the transaction. With WebDAV locks, modifications made while the lock existed remain after the lock expires or is removed.

• A sandbox is a way to work on data "out of sight" of other users so that other users do not see any changes until the transaction is committed. With WebDAV locks, any changes to the locked resource are visible to other clients.

The versioning extensions to WebDAV include rollback (uncheckout) and sandbox functionality (workspace or working resource), covered in Chapter 11, Versioning.

4.5.8 Removing Locks

The lock owner can remove the lock at any time. This request requires the lock token on an authenticated UNLOCK request. Ideally, client software would reliably unlock all resources when finished with them, but sometimes crashes occur or the network simply becomes unavailable to either the client or the server. Thus, the end of the timeout period also results in the removal of the lock (see Figure 4-8).

Figure 4-8. Lock life cycle.

Locks can also be removed by a specially privileged user such as the administrator or resource owner. The administrator might have to use special software, perhaps a special administrative tool, but the server policy may also allow UNLOCK requests with sufficiently privileged user identification. Thus, all WebDAV clients must be able to deal with locks that disappear before the expected timeout.

No matter how a lock is removed, changes made to the resource while it was locked are permanent changes.

4.5.9 Depth Locks: Locking Collections

To be completely WebDAV compliant, a server must support locks on collections if it advertises lock support at all. Microsoft IIS 5.0 is not completely compliant with WebDAV locking because it does not support locks on collections. The underlying file system does not support locks on folders, and IIS 5.0 stores all resources natively in the file system (and may allow them to be modified through local access, network file system protocols, or FTP).

What does it mean to lock a collection, since a collection doesn't have a body that can be changed? There are several ways in which a collection lock may prevent various operations.

1. Protect metadata: Only the lock holder may edit the collection's metadata.

2. Protect collection name and location in the hierarchy: Only the lock holder may move or rename the collection or any parent collection.

3. Protect the list of resources directly within the collection: Only the lock holder may add, delete, or rename any of the collection's children.

4. Protect the content of all the direct children: Only the lock holder may modify any of those children (as if each child were locked individually).

5. Protect the content of all of the collection's descendants: Only the lock holder may make any changes anywhere under the collection.

In WebDAV, any lock on a collection provides all of the protection described in items 1, 2, and 3. A full "tree" or infinite depth lock covers the last two items as well.

4.5.10 Shared Locks

Shared locks allow multiple users or processes to lock a file. Each holder of a shared lock can then supply the unique lock token for that lock to change the file. Each lock can be independently refreshed, timed out, or unlocked.

Shared locks do not show up very often, because shared locks require additional client coordination work. However, they do exist, and client software should not behave poorly when accessing a resource that happens to have multiple locks. If a client notices that a resource already has shared locks, the client should not take out another shared lock unless it has some way to know how the other lock holders are handling change control.

A frequent question is why WebDAV has shared locks in the first place, when exclusive locks offer stronger protection. The reason is that existing CM systems frequently had shared locks. The WebDAV designers wanted those systems to be able to implement WebDAV without major loss of functionality.