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

Re: Etag-on-write, 2nd attempt (== IETF draft 01)

From: Roy T. Fielding <fielding@gbiv.com>
Date: Tue, 12 Sep 2006 19:52:08 -0700
Message-Id: <C9E3C46F-1E6B-4CB2-983E-3279125B8EAB@gbiv.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
To: Lisa Dusseault <lisa@osafoundation.org>

On Sep 12, 2006, at 7:00 PM, Lisa Dusseault wrote:
> Yes, this is a good analysis.  I know there are significant client  
> deployments based on assuming no server-rewriting.  I am not aware  
> of server deployments that do rewriting and return strong ETags.   
> I'm thus quite confident about where the interop advantage lies.

I agree.  As I said last time, 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 (that includes IMS, If-Match, and Range- 
based
conditional requests).  There is absolutely no reason for the server  
to send
an ETag on a PUT response if the server does not intend to support that
functionality, and I am quite sure that none of the server vendors will
care provided that the requirement is properly stated as an interface
constraint and not an implementation constraint.

OTOH, the mechanism for how the server "stores" the representation,  
whether
or not it is stored byte-for-byte, and how a server might otherwise  
manage
to accomplish the feat of handling a conditional request without  
preserving
byte-level equality is none of our business and should never appear  
in an
IETF specification regarding HTTP.

....Roy
Received on Wednesday, 13 September 2006 02:52:19 GMT

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