W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2006

Apache ETag promotion (Re: I-D ACTION:draft-whitehead-http-etag-00.txt)

From: Wilfredo Sánchez Vega <wsanchez@apple.com>
Date: Fri, 3 Mar 2006 12:30:33 -0800
Message-Id: <AD08ECC0-26C5-4D21-BD26-DFA7B3248D04@apple.com>
To: HTTP Working Group <ietf-http-wg@w3.org>

   Some text for section 3, the Apache situation, is below.  Let me  
know if more info is needed here.


   Some HTTP servers, specifically the Apache web server, return  
ETags derived from data that includes the time stamp of the file.   
Usually the computed ETag for a given resource will be a strong  
ETag.  However, because the granularity of time stamps on files is  
discrete (in the worst cases, it is one second), if the resource was  
very recently created, this scheme produces an unreliable ETag; the  
resource may change several times within this initial time window,  
but the computed ETag would not, which violates the required  
semantics of ETags.  Therefore, during the initial time window, a  
weak ETag is computed instead.

   The effect of this is that when a resource is created, it starts  
with a weak ETag (eg. "W/Fri Feb 24 18:53:48 GMT 2006").  After the  
system clock proceeds past the initial time window, the resource has  
a strong ETag (eg. "Fri Feb 24 18:53:48 GMT 2006").

   Note that the weak ETag semantics are being abused to some degree  
here.  The server is deciding that any changes to the resource during  
the initial time window are semantically equivalent.  While the  
criteria for semantic equivalence are not defined by HTTP, this seems  
like a bit of a stretch beyond what most people would consider  
appropriate.  This does, however, have the desired effect for caching.

   Note also that after a PUT request, the ETag will almost always  
start in the weak state.  This makes the utility of the ETag returned  
on PUT rather marginal, if not useless, for authoring because it will  
almost certainly change the next time the client checks the ETag.
Received on Friday, 3 March 2006 20:30:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:27 UTC