Web Commander

Web Commander Solves the Lost Update Problem

The Lost Update Problem has been present in most distributed authoring sessions using rudimentary HTTP/1.0 features. the Web Commander can now demonstrate how to avoid this problem based on HTTP/1.1 features including persistent cache, strong etags, if-match header fields and HEAD requests.

A couple of notes:

• Web Commander uses the normal libwww Request API without modifications
• As the requests contain the TE header field indicating that the client understands deflate, the server sends back deflated and chunked responses
• Web Commander only detects conflicts - it doesn't try to resolve them

Testing Whether a Document Exists using HEAD Requests

If the user wants to save a document that we don't know anything about then we have to issue a HEAD request before doing a PUT.

• The first trace shows a situation where the document doesn't exist and the PUT request is executed normally
• The second trace shows a situation where the document already exists. The user is then given two options: two download the existing version or to override it. In the trace the user overrides the existing version.

Using the Etag in subsequent PUT Requests

When a new document has been created on the server, it sends back the etag in the 201 (Created) response. This etag is stored in our persistent HTTP/1.1 cache. Once the etag is known, it is used on all subsequent PUT requests in a if-match header field. If the resource has changed on the server the etags will no match and the PUT will not succeed. Instead the user will be given the same two options as above, that is, either to get the new version or to override it.

• This trace shows a PUT request with a if-match header field. In this situation the etag matches and the PUT request is executed. A new etag is sent back in the 204 (No Data) response. This etag is now saved in the persistent cache.