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.
[snip]
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
Cheers,
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
