Fw: Re: Our old friends, weak ETags

------ Forwarded Message ------
From: "Bruce Perens" <bruce@perens.com>
Subject: Re: Our old friends, weak ETags

On 07/19/2012 10:22 PM, Adrien W. de Croy wrote:
>Hi Bruce, thanks for your answer.. but is this _weak_ ETags or just 
>ETags in general?
[Please forward this to the mailing list, it won't let me post.]

Complicating the entire ETags issue is the fact that the responsibility 
to negotiate a content encoding is in a different layer than my 
application. It's happening in Phusion Passenger, or Nginx. So, that 
layer has to do something sensible with an existing ETag that is opaque 
to it. The choices are for it to put a Weak designator on that ETag, or 
to append some text to the ETag that is specific to the content 
encoding in use and is standardized across caches so that an arbitrarily-selected 
cache, not necessarily one you used for the previous request, can respond to a 
request appropriately.

>From the perspective of my web application and the browser's 
presentation, the content encoding is akin to a transport-layer 
property. It's transparent, its reversal yields data that is 
bit-identical to the unencoded version. It seems to me that this is 
what the Weak designator was intended for.

If the cache is allowed to be smart enough to negotiate content 
encoding and fulfill a request with the encoding it has on hand, there 
is a point to the Weak designator. If that's not to the case, we can 
make an well-defined change to the ETag per encoding and dispense with 
the Weak designator. But standardizing that change would probably be 
more work than supporting the Weak designator.

     Thanks

     Bruce