268844 - XMLHttpRequest caching is broken by unoverridable HTTP Headers

Status: RESOLVED FIXED

(Core :: XML, defect)

Description

[Jeremy Hartley]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041109

When the browser makes a request using  XMLHttpRequest the HTTP Request Headers
always contain the following two headers:

Cache-Control: no-cache 
Pragma: no-cache 

It is impossible to override these setting using the 
XMLHttpRequest::setRequestHeader method. Which results in disabled caching for
XMLHttpRequests which is highly undesirable, since it may be used to retrieve
static files which may be updated infrequently.



Reproducible: Always
Steps to Reproduce:
xmlhttp = new XMLHttpRequest(); 
     
xmlhttp.open("GET", "huge.xml",true); 
xmlhttp.onreadystatechange=function() { 
    if (xmlhttp.readyState==4) { 
        alert(xmlhttp.responseText); 
    } 
} 

xmlhttp.send(null); 

________________________________________________ 

This code will produce a GET Request with the following HTTP headers: 
Cache-Control: no-cache 
Pragms: no-cache 

I have tried to override the header values using commands like. 

    xmlhttp.setRequestHeader('Cache-Control', ''); 
    xmlhttp.setRequestHeader('Pragma', ''); 

This has no effect at all. 

Another attempt: 

xmlhttp.setRequestHeader('Cache-Control', 'Hello'); 
xmlhttp.setRequestHeader('Pragma', 'Hello'); 

Produces the following HTTP Headers: 
Cache-Control: Hello, no-cache 
Pragms: Hello, no-cache 

Which still seems to override any ability to use cached data.

Actual Results:  
The following HTTP Headers were visible:
Cache-Control: no-cache 
Pragms: no-cache 



Expected Results:  
I expected the headers to be overridable and to not appear or to be empty

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

http://lxr.mozilla.org/seamonkey/source/extensions/xmlextras/base/src/nsXMLHttpRequest.cpp#1532

-> xmlhttprequest code does this intentionally. changing component.

Comment 2

[Darin Fisher]

jst: perhaps XMLHttpRequest should have an attribute to control whether or not
it bypasses the local browser cache?  default enabled.

Comment 3

[Darin Fisher]

confirming bug based on comment #1.

Comment 4

[Johnny Stenback (:jst)]

(In reply to comment #2)
> jst: perhaps XMLHttpRequest should have an attribute to control whether or not
> it bypasses the local browser cache?  default enabled.

Or maybe just make it not set these headers if they were already set by the caller?

Comment 5

[Darin Fisher]

well, there's a difference between the headers and the load flags.  the load
flags require that necko insert some headers, but the choice of headers depends
on whether we are doing a proxy connection or a normal connection, etc. 
moreover, if the user wants us to not set these headers, then they'd need a way
to tell us not to set the load flags, right?

Comment 6

[Hixie (not reading bugmail)]

IE doesn't set these headers, relying on the server to decide whether it should
be cached or not. At the moment, the discrepency between Mozilla and IE on this
is quite confusing for authors (I speak from first-hand experience here!).

So I say: Remove the headers altogether!

Comment 7

[Johnny Stenback (:jst)]

Yeah, that would work too. I don't have a problem with that.

Comment 8

[Hixie (not reading bugmail)]

It's now law. Mwuhahahahaha.
   http://whatwg.org/specs/web-apps/current-work/#setrequestheader

(Comments on that spec are most welcome, by the way -- [e-mail])

Comment 9

[Darin Fisher]

Be careful.  Do we know why those load flags were added?  /me fears locking on
cache access or something like that as a result of GC not yet running.  Some CVS
archeology would be good.  Might also be good to ask heikki :-)

Comment 10

[Johnny Stenback (:jst)]

Attachment: Only force no caching for multipart http requests.

This should be what we want. The code to set these flags was added in bug
237319 since it doesn't make sense to cache multipart documents, and if there's
ever two that are racing, one will hit the server and one will get the content
from the cache, which is never what you want with a multipart request. This was
done for all requests due to Heikki's comment in bug 237319 about bug 200706,
but that really isn't a bug, the server can ensure that the appropriate headers
are sent in the cases where the document should be cached, etc etc...

Comment 11

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 165503 [details] [diff] [review]
Only force no caching for multipart http requests.

>Index: extensions/xmlextras/base/src/nsXMLHttpRequest.cpp
>+    // multipart mixed preplace documents.

s/preplace/replace/

r=bzbarsky

Comment 12

[Johnny Stenback (:jst)]

Fixed.

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 296901 has been marked as a duplicate of this bug. ***

Comment 14

[Phil Ringnalda (:philor)]

*** Bug 305422 has been marked as a duplicate of this bug. ***

Comment 15

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 348924 has been marked as a duplicate of this bug. ***

Comment 16

[bht237]

I apologise for re-opening it. Please correct me if I made an error. I have downloaded the latest version of Mozilla: Mozilla 1.7.12 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915

With this version, there is no cacheing of requests, with the test case that I am attaching. The easiest way I found to verify this was to download Apache 2.2 for Windows, install it and change httpd.conf parameters DocumentRoot and <Directory to the directory with the 3 attached files.

Comment 17

[bht237]

Attachment: Save as index.html, start here.

This page should be loaded from a web server whose access log you can view.<br>
Please press both buttons in an alternating way, many times.<br>
Then examine your web server's access log. The log file should have entries for each URL only once.<br><br>

Comment 18

[bht237]

Attachment: Save this as test1.htm

Comment 19

[bht237]

Attachment: Save this as test2.htm

Comment 20

[Christian :Biesinger (don't email me, ping me on IRC)]

1.7.x is unsupported