couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Lenz <>
Subject Re: Call for objections releasing 0.10
Date Wed, 16 Sep 2009 07:23:23 GMT
Hey Curt,

On 16.09.2009, at 07:38, Curt Arnold wrote:
> The spec appears to be walking a fine line with respecting behavior  
> of some HTTP 1.0 caches that treated expires in the past as  
> equivalent to no-cache.   See section 14.9.3, where HTTP 1.1 caches  
> are instructed to assume no-cache if they see an Expires date in the  
> past without a Cache-Control header.  CouchDB does send a Cache- 
> Control, so we would not be affected by that.
> Within RFC 2616, the description of the treatment of "Expires 0",  
> the note in section 14.9.3 and section 14.18.1, all seem to  
> acknowledge the use of Expires in the long past.  RFC 2109 had this  
> quote that indicated that at least in 1997, having a fixed Expires  
> date in the past was a common pattern.
> In my testing (as mentioned in the bug report), max-age=0 was  
> insufficient to prevent stale requests if subsequent reads occurred  
> within the same second.  I have not tested Expires == Date, but I  
> think there is a possibility that some clients might still have a  
> window where you can get stale depending on the client.  Setting max- 
> age=0 is clearly within the spec and would likely reduce the user  
> experiences of conflicts due to stale data, but would not be  
> sufficient to get the unit tests to work unless you added explicit  
> waits.

Doh, you're right, and I got the role of the Expires header wrong.  
I've reopened the issue.

I don't have time for testing whether this actually works as you  
describe across all the major user agents. But as long as we're doing  
the right thing with respect to the HTTP spec, I think this is the way  
to go.

So, I stand corrected and retract my -1, and everything else I said  
based on my incorrect assertion :P

Christopher Lenz
   cmlenz at

View raw message