Re: ETags and concurrency control

On fre, 2008-05-02 at 19:37 +0200, Werner Baumann wrote:

>  From this common use of weak etags, it makes sense to not allow weak 
> etags in PUT (lost update problem), but to allow it in full body GET (in 
> case the entity changed, the damage is usually small).

Wait a minute here. The "weak" ETags generated by Apache isn't that
weak. For Apache in default configuration to generate the same weak ETag
for two different versions the following need to all be true

- The update was done in-place by overwriting parts of the file,
preserving the same inode number.
- The update MUST be within the same sub-second as the previous update
- The update MUST NOT change the file size.
- The inode change timestamp must also not change by the update.

This can practically only happen if there is other processes updating
the file content directly outside Apache.

The reason why Apache sends weak ETag on content modified in the last
second is because the default configuration assumes there will be other
processes running on the server "randomly" overwrite parts of published
files many times within the same second.

For normal HTTP use where updates is done using PUT, or nearly all
normal edits the above isn't true and Apache may just as well send a
strong ETag without any loss of guarantee.

Regards
Henrik

Received on Friday, 2 May 2008 18:41:05 UTC