couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: Call for objections releasing 0.10
Date Wed, 16 Sep 2009 03:06:59 GMT
On Tue, Sep 15, 2009 at 7:55 PM, Curt Arnold <> wrote:
> On Sep 15, 2009, at 5:30 PM, Christopher Lenz wrote:
>> This is a somewhat misleading description; it's not the lack of an Expires
>> header on CouchDB responses that results in incorrect caching, it's a
>> (really ugly) bug in the XMLHttpRequest implementation of IE6 that does
>> this. As far as I know, the cache control headers sent by CouchDB are
>> absolutely correct according to the HTTP specification. Unconditionally
>> adding an Expires header (with a date in the past) just to workaround the
>> XHR bug in IE6 *completely disables* any caching by any user agent!
> One of the earlier patches did, but the current patch has no negative effect
> on other browsers (other than adding 20 or so bytes to the header) and
> brings XmlHttpRequest's behavior into line with the other browsers.  Adding
> Expires in conjunction with the must-revalidate simply explicitly declares
> that any reuse of previously cached documents must be revalidated with the
> server.  There is no time that the document is fresh and does not need
> revalidation.  Without the Expires header, other browsers guess what we'd
> like them to (that the document isn't fresh) and IE 6's XmlHttpRequest uses
> heuristics and typically guesses that the document is fresh.  Adding an
> Expires header in the past (or a value of 0) is explicitly mentioned in the
> HTTP RFC as the mechanism to mark as response as immediately stale.  I kept
> the date in the past (though I would have preferred sending a 0) since one
> of the UUID tests was over-specified and would fail if it didn't have a
> valid date.
> I've monitored the traffic and the logs before and after the patch and see
> exactly what I would expect.  Second requests to unchanged documents get a
> 304 returned from the CouchDB and use the previously retrieved value on
> every browser I've tried.  Fire up Fiddler or your favorite network
> monitoring tool and see for yourself.
>> Note also that IE6 gets cache invalidation right when you don't go through
>> XMLHttpRequest (that is, request CouchDB documents/views directly).
>> A CouchDB-based application that runs on the client (CouchApp-style), and
>> that needs to work on IE6, has the option to force all XHR requests to
>> invalidate the cache (for example by using jQuery's "cache=false" option to
>> AJAX requests, which simply adds an extra timestamp-valued query string
>> parameter). In addition, it can choose to do so if, and only if, it detects
>> to be running on IE6. And of course, applications accessing CouchDB only
>> through server-side code do not need to care about this issue at all.
>> Presumably we *could* add the browser detection and the conditional
>> addition of an Expires header to the CouchDB HTTP server, but browser
>> detection is a really slippery slope that I think we should avoid, and IE6
>> is likely (or so I hope) to be pretty much extinct by the time CouchDB
>> reaches the 1.0 mark. In any case, I'm -1 on any patch that does this
>> unconditionally, and -0.5 on any patch that does the Expires header dance
>> conditionally. I'd be okay with adding the cache busting trick to Futon (but
>> again, only conditionally), and documenting the issue and workaround for
>> CouchApps.
>> Cheers,
> The unconditional Expires header is the simplest fix.  As far as I can tell,
> it has no undesirable effects and accomplishes the goal.  If that doesn't go
> in, then I'd prefer to see the header values being configurable instead of
> baking in other logic.

The most efficient use of CouchDB's Etags is to apply a caching proxy
in front, which does not revalidate immediately. That is, you
configure your proxy so that if it receives requests for a resource at
a high rate, the cache only makes conditional GETs at most once a
second, or whatever stale duration is acceptable in your application.

> I don't want to get in a reopen war, but please reopen the bug.

I'm wary about adding cache busting headers, even if they seem to
work, because they'll probably start busting intermediaries that are
properly caching now. I think IE 6 support should happen on the client

That said, I wouldn't be -1 on an optional configuration to send cache
busters, but I'm not happy about the idea of doing it by default, even
with browser sniffing.


Chris Anderson

View raw message