On 16 Sep 2009, at 00:30, Christopher Lenz wrote:
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.
Thanks for the apt analysis (again).
-1, too.
Cheers
Jan
--
