Re: Summary of ETag related issues in RFC2518bis

Ted Hardie wrote:
> At 11:50 PM +0100 12/19/05, Julian Reschke wrote:
>> Jim Whitehead wrote:
>>> I'd like clarification as well.
>>>
>>> It's fine for WebDAV to place additional requirements on base HTTP servers. I don't see anything in the definition of PUT or of the Etag header that would prevent Etag being returned by PUT.
>> That's not the issue here.
>>
>> The question here is whether an ETag returned upon PUT is for the entity the client sent (1), or for the entity the server would send upon a subsequent GET (2).
> 
> I have personally always assumed that an ETag returned on a PUT is for the entity the client sent , and that if what the client would get at a subsequent GET was different, the ETag changed.  It's not clear to me how a subsequent range request would work interoperably if this were not the case, as it seems to require that the client understand what transformation the server is going to perform (that is, the client would have to somehow know what the bits would be after its PUT).   It certainly seems easier to me to code a conditional with this assumption.
> 
> Just my personal opinion,
> 			regards,
> 				Ted Hardie

Ted,

thanks a lot for the feedback. As a matter of fact, I thought the same 
until recently when I asked on the HTTP mailing list. Scott Lawrence 
(<http://lists.w3.org/Archives/Public/ietf-http-wg/2005OctDec/0014.html>), 
  Mark Baker 
(<http://lists.w3.org/Archives/Public/ietf-http-wg/2005OctDec/0016.html>), 
and Henrik Frystyk Nielsen 
(<http://lists.w3.org/Archives/Public/ietf-http-wg/2005OctDec/0017.html>) 
  disagreed with that point of view (and this was the only feedback, 
except for agreement that RFC2616 should be clarified).

This is why I think that we shouldn't PUT^h^h^hput in this requirement 
unless we tell people what it means, and we make sure we are in 
agreement with what a potential revision of RFC2616 is going to say 
about it.

Best regards, Julian

Received on Monday, 19 December 2005 23:26:40 UTC