Stronger requirements for ETags

Currently rfc2518bis-03 says:

"HTTP 1.1 suggests the use of the ETag header in responses to GET and PUT requests. Correct use of ETags is even more important in a distributed authoring environment, because ETags are necessary along with locks to avoid the lost-update problem.  A client might fail to renew a lock, for example when the lock times out and the client is accidentally offline or in the middle of a long upload.  When a client fails to renew the lock, it's quite possible the resource can still be relocked and the user can go on editing, as long as no changes were made in the meantime. ETags are required for the client to be able to distinguish this case. Otherwise, the client is forced to ask the user whether to overwrite the resource on the server without even being able to tell the user whether it has changed. Timestamps do not solve this problem nearly as well as ETags.

"WebDAV servers SHOULD support strong ETags for all resources that may be PUT.  If ETags are supported for a resource, the server MUST return the ETag header in all PUT and GET responses to that resource, as well as provide the same value for the 'getetag' property. 

"Because clients may be forced to prompt users or throw away changed content if the ETag changes, a WebDAV server MUST not change the ETag (or getlastmodified value) for a resource when only its property values change. The ETag represents the state of the body or contents of the resource. There is no similar way to tell if properties have changed."

Some history on how we got here:  RFC2518 doesn't require ETags, nor does HTTP.  But the overwrite problem isn't truly soluble without support for ETags (or some other untested new mechanism).  Thus, at the early-2003 interim meeting, the attendees agreed to strengthen requirements for ETags.

Draft 2518bis-02 required:

"WebDAV servers MUST support ETags correctly and MUST return the ETag header
in all GET and PUT responses. " 

However this was argued on the list to be too strong, and was weakened to the language already shown in -03.

So, what now?  Does the current language (03) make mod_dav or IIS (or other implementations) uncompliant with 03?  Is that a problem?  Would it be a bad idea to upgrade mod_dav or IIS to become compliant with RFC2518bis if it goes to RFC with these requirements?  I'd point out that there are other changes that already make servers slightly uncompliant with RFC2518bis -- e.g. the removal of specially-behaving lock-null resources makes existing servers supporting lock-null resources "uncompliant".  But being uncompliant with a spec that the server doesn't declare compliance to shouldn't be a problem!  A server will continue to be compliant with 2518 because that can never be replaced. Server implementors may upgrade their code/product to become compliant with RF2518BIS (whatever rfc number that turns out to be) and then declare compliance with that new, more stable standard.

IF the language must be weakened, is there any point to this at all?  I'm afraid we've got to make a hard choice.  Either we do something real to encourage ETag support, even though it makes existing servers "uncompliant".  Or we do nothing, and we leave the problem unmitigated.

As a server implementor, my personal opinion is that it's a good idea to make, and follow, stricter requirements for ETag support.  It's so helpful to clients and users (in terms of robust and reliable distributed authoring) that it's worth the cost.   

Lisa

Received on Saturday, 21 June 2003 19:27:12 UTC