[ 
https://issues.apache.org/jira/browse/COUCHDB-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14136840#comment-14136840
 ] 

Robby Morgan commented on COUCHDB-257:
--------------------------------------

Hi Joan, thanks for jumping in on this so quickly.  I apologize that my initial 
comment was quite brief, but I was in still in the midst of understanding why 
IE was considered "broken", other than the fact that it has always differed 
from Chrome and Firefox.  I understand your unwillingness to touch this issue, 
since there are lots of broken HTTP caches out there, and it seems like this is 
a case where IE is in that camp.

With that said, I've done some more thinking on this, and I'd like you and 
other (awesome!) CouchDB developers to consider this:

One of the key strengths IMO of CouchDB is its ability to operate as its own 
app server, so the browser can connect directly to it.  However, that strength 
is severely undermined if developers can't ensure that XHR requests to CouchDB 
will actually be refetched by IE, even in the modern versions, when the user 
reloads the browser.  It's frustrating that the only workaround to date seems 
to be putting some web server in front of CouchDB to add the necessary headers, 
so I'd like to understand the objections to any proper resolution in CouchDB in 
more detail.

If I'm analyzing CouchDB's current behavior, I can see that CouchDB (as of 
1.5.1 -- sorry I haven't upgraded yet) and Cloudant return two headers with 
each GET:
 * A proper "ETag" header, which permits conditional GET requests, and
 * "Cache-Control: must-revalidate", which on its face seems to instruct the 
browser to issue an conditional GET before reusing the response for future 
requests.

As previous commenters [Vinay|#comment-12674650], [Mark|#comment-12737879], 
[Curt|#comment-12750507], and [Christopher|#comment-12755916] have all 
concluded, this is not sufficient to instruct HTTP caches and user agents that 
subsequent requests require immediate revalidation.  To achieve that, it is 
necessary to specify some expiration criteria through either the "Expires" 
header or the "max-age=" property of "Cache-Control".  

Almost 5 years ago, it seems like Curt came to the conclusion that Expires is 
necessary (and per the spec, it doesn't hurt to be redundant), and he developed 
a patch that would solve this issue.  Then there was some initial objections 
based on a cursory review of the ticket that were withdrawn shortly thereafter, 
and then nothing happened until someone incorrectly assumed that this issue was 
specific to IE6, and closed the ticket.

I've now reviewed the HTTP spec (especially sections 14.9.4, 13.2.2, and 
13.2.4), and I agree with the previous commenters that the ideal solution to 
this issue is for CouchDB to have a configure max-age parameter, which is 0 (or 
-1) by default.  

I also want to make it clear that this issue is about CouchDB correctly 
instructing HTTP caches to revalidate every GET response -- I don't agree that 
IE's behavior is obviously wrong, since CouchDB is effectively ceding control 
of response staleness to IE's own internal heuristics.  As such, I think the 
title of this issue should be "HTTP caching is inconsistent across clients due 
to lack of response expiration headers", but as a newcomer to the community, 
I'm not presumptuous enough to update the title myself.

In summary, please reopen this issue for consideration.

> HTTP caching headers make Internet Explorer experience poor
> -----------------------------------------------------------
>
>                 Key: COUCHDB-257
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-257
>             Project: CouchDB
>          Issue Type: Bug
>          Components: HTTP Interface
>    Affects Versions: 0.8.1, 0.9
>         Environment: Server: Ubuntu Hardy on x86. Client: Windows XP (32-bit).
>            Reporter: Vinay Sajip
>            Priority: Minor
>              Labels: wontfix
>         Attachments: caching-header-patch.diff, expires.patch
>
>
> The HTTP caching headers currently put out cause IE (for example) to not 
> display information correctly in Futon. It's easy to reproduce: I open 
> windows in Firefox and IE simultaneously, do an update using Firefox (e.g. 
> add a new document) and refresh the IE window. The updated document count is 
> not shown. If I clear the browser cache and try again, the updated 
> information is displayed.  The HTTP header put out is
> Cache-Control: must-revalidate
> which seems to me insufficient - for IE, at least. Is there way of 
> configuring these headers, to for example 
> Cache-Control: no-cache
> Pragma: no-cache
> Expires: some date in the past, or the same value as the Date: header
> Christopher Lenz has said about this that "This is due to extra-aggressive 
> (and against the HTTP spec) caching   that IE does on XMLHTTPRequests. A 
> patch would need to do user agent sniffing to conditionally add the  "cache: 
> false"  parameter to the jQuery ajax() invocations in   jquery.couch.js (and 
> maybe elsewhere). I wouldn't want to add this for all user agents, as it 
> basically circumvents any caching for AJAX  requests (even for 
> not-craptastically-broken implementations), and  thus would add quite a bit 
> of unnecessary overhead."
> To this, I would comment that I don't believe a patch to the client-side code 
> in Futon would be sufficient. There are other clients out there, some of 
> which will be on Windows and so by default use the (acknowledgely broken) 
> Microsoft stack. In my view it is more important to err on the side of 
> correctness than performance - so I believe the headers generated server-side 
> need to change, as well as perhaps Futon client-side changes.
> I note that handle_uuids_req in couch_httpd_misc_handlers.erl uses the 
> no-cache/Expires scheme I mention.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to