Re: Stronger requirements for ETags

Hi,

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!
>
Agreed.

>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 
clear.

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


Cheers,
Elias

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