Closed Bug 268844 Opened 21 years ago Closed 19 years ago

XMLHttpRequest caching is broken by unoverridable HTTP Headers

Categories

(Core :: XML, defect)

x86
Windows XP
defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: jeremy, Unassigned)

References

()

Details

Attachments

(4 files)

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
http://lxr.mozilla.org/seamonkey/source/extensions/xmlextras/base/src/nsXMLHttpRequest.cpp#1532 -> xmlhttprequest code does this intentionally. changing component.
Assignee: darin → core.xml
Component: Networking: HTTP → XML
QA Contact: core.networking.http → ashshbhatt
jst: perhaps XMLHttpRequest should have an attribute to control whether or not it bypasses the local browser cache? default enabled.
confirming bug based on comment #1.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(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?
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?
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!
Yeah, that would work too. I don't have a problem with that.
It's now law. Mwuhahahahaha. http://whatwg.org/specs/web-apps/current-work/#setrequestheader (Comments on that spec are most welcome, by the way -- whatwg@whatwg.org)
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 :-)
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...
Attachment #165503 - Flags: superreview?(darin)
Attachment #165503 - Flags: review?(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
Attachment #165503 - Flags: review?(bzbarsky) → review+
Attachment #165503 - Flags: superreview?(darin) → superreview+
Fixed.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
*** Bug 296901 has been marked as a duplicate of this bug. ***
*** Bug 305422 has been marked as a duplicate of this bug. ***
*** Bug 348924 has been marked as a duplicate of this bug. ***
Summary: XMLHttpRequest caching is broken by unoveridable HTTP Headers → XMLHttpRequest caching is broken by unoverridable HTTP Headers
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
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>
Attached file Save this as test1.htm
Attached file Save this as test2.htm
1.7.x is unsupported
Status: REOPENED → RESOLVED
Closed: 21 years ago19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: