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

### Saving a Document for the First Time

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 the save using a `PUT` request. The `HEAD` request is necessary as we don't know whether we are speaking to an HTTP/1.0 or an HTTP/1.1 server - only the latter understands etags. Note, that the `PUT` request uses the "`If-None-Match: *`" header field to ensure that no race condition occurs between the two requests. There are two situations that have to be handled:

The document doesn't already exist
  The first trace shows a situation where the document doesn't exist and the `PUT` request is executed normally
The document already exists
  The second trace shows a situation where the document already exists. The user is then given two options in a GUI dialog box: to download the existing version or to override it. In the trace the user overrides the existing version which is done by removing any preconditions.

### Saving a Document for the 2nd or more Time

When a new document has been created on the server, it sends back an 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 document hasn't changed, the etags will match and the `PUT` can proceed. However, if it has changed, then the etags will not match and the `PUT` can not proceed. Instead the user will be given the same two options as above, that is, either to get the new version or to override it.

The document has not been changed
  This trace shows a `PUT` request with a `if-match` header field. In this situation the etag matches and the `PUT` request is executed as normal.
The document has been changed
  The last trace shows a situation where someone else updated the document and so the etags don't match anymore. THe PUT therefore fails and the user is then presented with the option of downloading the new version of overriding the existing one. In this case, the existing version is simply overridden.

In both cases, the new etag sent back is saved in the persistent cache and the old etag deleted.