couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <jch...@apache.org>
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 <carnold@apache.org> 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
side.

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

-- 
Chris Anderson
http://jchrisa.net
http://couch.io

Mime
View raw message