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
The document doesn't already
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
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
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.
Henrik Frystyk Nielsen,
@(#) $Id: NoMoreLostUpdates.html,v 1.2 1998/12/05 17:50:33 frystyk Exp $