Hi, I was trying to write a simple ajaxy application to learn Mochikit. The URL above calls some simple JS functions which get a static file periodically and print the HTTP status response code. I use the If-Modified-Since and If-None-Match header fields to simulate a conditional get. The expectation is that the the alert window will show 200 the first time and then 304 subsequently. This behaviour is demonstrated with Internet Explorer 6.0/Windows and Firefox 1.0.7 on MacOSX. However if I use Firefox 18.104.22.168 on Windows 2000/XP and MacOSX I am only shown '200' in the alert box on the first time and then on subsequent call outs.
Target Milestone: mozilla1.8final → mozilla1.8.1
If I change the pref network.http.use-cache from true to false. Firefox behaves as expected. I have changed the component to networking.
Component: XML → Networking: HTTP
sorry for bugspam, really meant networking:cache
Component: Networking: HTTP → Networking: Cache
I've also filed a corresponding bug in WebKit's bugzilla as well as via Apple's Radar http://bugzilla.opendarwin.org/show_bug.cgi?id=8210
> I have changed the component to networking. You want to change the assignee when you do that if you expect someone to notice....
Assignee: xml → nobody
QA Contact: ashshbhatt → networking.cache
So, what is the intended behavior of XMLHttpRequest? As I understand it, both the W3C and WhatWG have made efforts to standardize XMLHttpRequest. Is there a spec for what should happen if these request headers are set?
anne: please ensure your spec covers this. If it already does, please provide a link to the relevant section. Thanks!
Look for HTTP cache in http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/publish/XMLHttpRequest.html#dfn-send Please send comments to firstname.lastname@example.org.
OK, well that certainly supports this bug. -> Core: Networking: HTTP
Component: Networking: Cache → Networking: HTTP
QA Contact: networking.cache → networking.http
Would consider a fix for this regression in 22.214.171.124, but it's not going to write itself assigned to email@example.com -- anyone actively working on this?
Would need a tested trunk and 1.8 branch patch before we can consider it for the 1.8.0 branch. Not blocking, but if you get such a patch you can ask for approval on it and we'll consider it.
Assignee: nobody → darin
Flags: blocking126.96.36.199? → blocking188.8.131.52-
Darin - any thoughts on what the right fix is here?
Flags: blocking1.8.1? → blocking1.8.1+
Draft is now located at http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/Overview.html?content-type=text/html;%20charset=utf-8#dfn-send ... This hasn't changed though.
I can reproduce the behavior difference FF1.0 and FF1.5. I'm investigating to see what changed.
OK, this bug appears to be caused by the fact that we no longer send 'Pragma: no-cache' and 'Cache-control: no-cache' with each XMLHttpRequest GET. I didn't realize that Firefox 1.0 did that, but it seems like a good thing that Firefox 1.5 does not. The 304 is still happening, however, it is just happening transparently to the application. Necko reports a 304 as a 200 since it is able to re-use its cached copy. Perhaps it should realize that the consumer is initiating the conditional request and skip trying to use its own cache.
Here's the old code where the local cache was unconditionally bypassed: http://lxr.mozilla.org/aviary101branch/source/extensions/xmlextras/base/src/nsXMLHttpRequest.cpp#1543 The change was made in bug 268844. The fact that conditional queries ever worked in Firefox 1.0 is simply an unintended side-effect of our support for multipart queries (which was added in bug 237319 just before we branched for Firefox 1.0). I think this bug should be fixed inside Necko's HTTP implementation.
Created attachment 226581 [details] [diff] [review] v1 patch
Attachment #226581 - Flags: superreview?(bzbarsky) → superreview+
Created attachment 226714 [details] [diff] [review] v1.1 patch Here's a slightly better variant on the same patch that biesi suggested.
13 years ago
Attachment #226714 - Flags: review?(cbiesinger) → review+
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
What effects (if any) might this have on stuff other than XMLHttpRequest?
Comment on attachment 226714 [details] [diff] [review] v1.1 patch It might be worth back-porting this fix to the 1.8.0 branch.
Attachment #226714 - Flags: approval184.108.40.206?
Comment on attachment 226714 [details] [diff] [review] v1.1 patch approved for 1.8.0 branch, a=dveditz for drivers
Attachment #226714 - Flags: approval220.127.116.11? → approval18.104.22.168+
Grr.. the patch did not apply cleanly to the 1.8.0 branch :-(
using testcase described in comment #0 Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:22.214.171.124pre) Gecko/20060825 Firefox/126.96.36.199pre verified 188.8.131.52 Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1b2) Gecko/20060825 BonEcho/2.0b2 verified 1.8.1b2
Status: RESOLVED → VERIFIED
Keywords: fixed184.108.40.206, fixed1.8.1 → verified220.127.116.11, verified1.8.1
You need to log in before you can comment on or make changes to this bug.