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

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- 
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,  
or not it is stored byte-for-byte, and how a server might otherwise  
to accomplish the feat of handling a conditional request without  
byte-level equality is none of our business and should never appear  
in an
IETF specification regarding HTTP.


Received on Wednesday, 13 September 2006 02:52:19 UTC