On 15.09.2009, at 16:02, Curt Arnold wrote:
On Sep 15, 2009, at 5:00 AM, Noah Slater wrote:
I plan on cutting the 0.10 release for a vote today.
I would like to collect any objections now before I go through the
motions.
I'd really like to see http://issues.apache.org/jira/browse/COUCHDB-257
and http://issues.apache.org/jira/browse/COUCHDB-345 integrated.
Neither are regressions, but they both address significant issues
and are pretty trivial amounts of code.
Without the fix for COUCHDB-257, any attempt to access CouchDB from
IE 6 (not sure about 7) will result in stale documents being used in
the app since the lack of an Expires tag results in the browser
always considering the previously retrieve version fresh. There is
not a new test case for it since the many test cases in the suite
fail on IE already, likely many because of this issue. However,
there is a test that you can drop into Futon to test this issue in
isolation. Though I would not recommend IE 6 to anyone, it is still
the browser of choice in some organizations.
[snip]
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!
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,
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
