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:
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:
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.
In both cases, the new etag sent back is saved in the persistent cache and the old etag deleted.