Re: Summary of ETag related issues in RFC2518bis

   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 21:54:57 UTC