W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2003

Re: Stronger requirements for ETags

From: Elias Sinderson <elias@cse.ucsc.edu>
Date: Tue, 24 Jun 2003 08:14:46 -0700
Message-ID: <3EF86AE6.8060300@cse.ucsc.edu>
To: Webdav WG <w3c-dist-auth@w3c.org>


Comments inlined below...

Lisa Dusseault wrote:

>Currently rfc2518bis-03 says:
>"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. 
>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?
In this respect the -03 language doesn't make them uncompliant, just 
weakly compliant, IMO.

>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 don't see this as a problem and think it would be a good idea all 
around for mod_dav and IIS to upgrade and support ETags.

>I'd point out that there are other changes that already make servers slightly uncompliant with RFC2518bis [...] But being uncompliant with a spec that the server doesn't declare compliance to shouldn't be a problem!

>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.
I wish there was something stronger than SHOULD and weaker than MUST, 
something along the lines of 'REALLY, REALLY SHOULD'...  :-) 
 Personally, I'm in favor of MUST, even with the difficulties it would 
create - growing pains are temporary and, as has been pointed out on 
several occasions, the benefits to both client authors and end users are 

Side note: Correct me if I'm wrong, but generating strong ETags just 
doesn't seem all that difficult to me...

Received on Tuesday, 24 June 2003 11:14:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:29 UTC