Re: Summary of ETag related issues in RFC2518bis

If I'm a client that has an exclusive write lock, then if I PUT to  
that resource, the stored entity should not be modified by anyone  
other than the server. In this case, which is the most common one for  
DAV-based editing, it's still very useful for the client to receive  
the final etag value in the response to PUT. Why? It saves the client  
from having to poll an uncertain number of times before it receives  
the final, stable etag value.

I still feel that R2 is required.

- Jim

On Dec 19, 2005, at 5:13 PM, Wilfredo Sánchez Vega wrote:

>
>   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 02:16:20 UTC