W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

Re: Summary of ETag related issues in RFC2518bis

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Wed, 21 Dec 2005 11:02:43 -0500
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Dan Brotsky <dbrotsky@adobe.com>, w3c-dist-auth@w3.org
Message-ID: <OF2EB54D6D.B6FE006C-ON852570DE.0057CBBF-852570DE.005823C3@us.ibm.com>
Julian Reschke <julian.reschke@gmx.de> wrote on 12/21/2005 10:02:23 AM:

> Dan Brotsky wrote:

> > I believe all of these things that clients want are accomplished with
> > what we have, as long as we have servers hand back strong etags on 
PUT.
> 
> 1) Servers may not be able to return strong ETags upon PUT. Again, let's 

> consider adding an indicator to PUT that let's the server know the 
> client really needs a strong ETag, so that the server can optimize it's 
> behavior for that case.

I agree.

> 2) It seems to me that we can't rule out that servers touch the ETag 
> upon PROPPATCH (for instance, because they are indeed updating metadata 
> in the file content, such as with XMP). In which case telling the server 

> to return the new ETag upon PUT seems to be a very good idea.

Did you mean, return the new ETag upon PROPPATCH?

Cheers,
Geoff
Received on Wednesday, 21 December 2005 16:03:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:12 GMT