RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)

It's still possible to make a stronger statement about Etag support in
2518bis.  Servers that are compliant with that, whatever RFC number it
will be (maybe '4???'? )  must support strong Etags. Servers that are
compliant with RFC2518 don't need to.

I'm guessing Some clients will interoperate against both RFC2518 servers
and RFC2518bis servers since they're very similar. But eventually,
clients will be written that want the guarantees of "bis", including
Etag support, and these clients will prefer to interoperate with servers
supporting "bis".

lisa

> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de] 
> Sent: Tuesday, February 25, 2003 5:27 PM
> To: Lisa Dusseault; 'Clemm, Geoff'; 'Webdav WG'
> Subject: RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)
> 
> 
> Lisa,
> 
> I agree with the statement that etags are useful. Etags on 
> their own are
> useful. ETags in conjunction with locking are even more 
> useful. I doubt
> anybody disagrees.
> 
> The issue we've been debating recently whether this justifies 
> to *require*
> etags. My recent tests with IIS and Apache/Moddav show that 
> upon a PUT, all
> you get is a weak etag, which clearly demonstrates that it is 
> non-trivial to
> produce robust etags when your backend is a filesystem. So, 
> IMHO, we really
> *can't* require strong etags, and weak etags really do not help.
> 
> So yes, there must be a safe way for a client to discover the 
> server's etag
> support (supported live properties, allprop, propname and 
> GET/HEAD behaviour
> MUST match), but that's it.
> 
> If a client doesn't want to communicate with a resource that 
> doesn't provide
> strong etags, it certainly can (and should be able) to do so. 
> I think that's
> all RFC2518bis should say.
> 
> Julian
> 
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 
>

Received on Tuesday, 25 February 2003 21:37:54 UTC