Re: Summary of ETag related issues in RFC2518bis

   There is no such thing as a final etag value.  Why pretend there  
is?  The tag could change for any number of reasons, including  
someone coming along and changing the content right after your PUT.

   Absent some reliable notification mechanism, there is no way to  
know that your locally cached copy is what's presently on the server,  
regardless of whether the server gives you a stable etag in the PUT  
response or not.  So this requirement doesn't get you what you are  
wishing for.

	-wsv


On Dec 19, 2005, at 1:20 PM, Jim Whitehead wrote:

> R2) Require servers to return entity tags for PUT requests
>
> Required. Or, put another way, what clients need is the ability to  
> know the final value of the etag assigned to the server's  
> representation of the resource created by a successful PUT. It  
> seems that the best way to do this is to have the server respond  
> with that Etag in the PUT response. What might also work is for  
> there to be a guarantee that this final etag will be available  
> within a given time period, and hence clients will only need to  
> perform a single follow-on request to get this etag. However,  
> protocol requirements involving timing are usually very hard to get  
> right -- it's not my first choice. That's why I think returning the  
> etag in the PUT response is the best way to communicate this final  
> etag value.

Received on Tuesday, 20 December 2005 01:14:01 UTC