Re: Summary of ETag related issues in RFC2518bis

   This makes sense, assuming Content-MD5 on the PUT response  
describes what the server is storing.  The client can then use that  
to compare with what they send and thus detect that the server stored  
something different.  This would avoid the need for a subsequent GET  
request if the checksum matches what was sent.

	-wsv


On Dec 20, 2005, at 2:06 PM, Lisa Dusseault wrote:

>
> Perhaps Content-MD5 would help solve a number of these issues in a  
> much cleaner way.  It doesn't do away with ETags I suspect, but can  
> help with PUT equivalence.
>
> Lisa
>
> On Dec 20, 2005, at 1:54 PM, Wilfredo Sánchez Vega wrote:
>
>>
>>   I don't see how that would help.  For one, I suspect may clients  
>> will ask for this all the time, so then why not do it for all  
>> clients all the time?  I'm not opposed to giving you the strong  
>> ETag, I just don't know how to do it.
>>
>>   One possibility is not to return an ETag at all on PUT, nor for  
>> GET requests in the first second, and only return the strong ETag  
>> once we know what it is.  This eliminates the weak ETag altogether.
>>
>>   The advantage here is that while the client would have to poll a  
>> few times to get the ETag, it would now when it got the "final"  
>> ETag that Jim is advocating for, once it got any ETag at all.   
>> However, for the first second, the file would not be cacheable,  
>> which is more or less correct anyway.
>>
>> 	-wsv
>>
>>
>> On Dec 20, 2005, at 12:46 AM, Julian Reschke wrote:
>>
>>> But it seems that there's a simple way to fix this (for Apache):  
>>> should a client require a strong ETag upon PUT, it could make  
>>> that explicit in the request (new header?), so that the server  
>>> can just special-case this, and do what's needed to ensure the  
>>> ETag is stable. Wilfredo?
>>
>>
>

Received on Tuesday, 20 December 2005 23:14:16 UTC