W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2006

Re: I-D ACTION:draft-reschke-http-etag-on-write-00.txt

From: Roy T. Fielding <fielding@gbiv.com>
Date: Thu, 10 Aug 2006 19:20:41 -0700
Message-Id: <14D6BBA0-9602-4286-B15A-F05A16FCB1EE@gbiv.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
To: Julian Reschke <julian.reschke@gmx.de>

On Aug 9, 2006, at 1:32 PM, Julian Reschke wrote:

> Personally, I think that we really need a very minor clarification,  
> plus a simple new feature to help clients that want to avoid a re- 
> fetch after sending the content. I therefore decided to write up my  
> own draft. It summarizes the situation (as RFC2616 is concerned),  
> proposes one clarification to RFC2616 (as mentioned in <http:// 
> lists.w3.org/Archives/Public/ietf-http-wg/2006JanMar/0003.html>),  
> and also proposes that minor new feature (a new response header).

No thanks.  A new response header will just be interpreted as an entity
header.  The easier solution is to simply require that ETag in a  
response
to PUT means that the client can use that entity tag in future  
conditional
requests.  How the server manages to accomplish that feat if it isn't
storing things octet-for-octet is none of your business.

Note that this will solve your problem without requiring that the server
become a filesystem, and is also consistent with XCAP (even though XCAP
is a really bad use of HTTP).  In spite of the overspecification in  
CALDAV,
the implementation will work fine as well for the above case.

....Roy
Received on Friday, 11 August 2006 02:20:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:46 GMT