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 126.96.36.199 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.
If I change the pref network.http.use-cache from true to false. Firefox behaves as expected. I have changed the component to networking.
sorry for bugspam, really meant 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....
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 email@example.com.
OK, well that certainly supports this bug. -> Core: Networking: HTTP
Would consider a fix for this regression in 188.8.131.52, but it's not going to write itself assigned to firstname.lastname@example.org -- 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.
Darin - any thoughts on what the right fix is here?
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
Created attachment 226714 [details] [diff] [review] v1.1 patch Here's a slightly better variant on the same patch that biesi suggested.
11 years ago
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.
Comment on attachment 226714 [details] [diff] [review] v1.1 patch approved for 1.8.0 branch, a=dveditz for drivers
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:184.108.40.206pre) Gecko/20060825 Firefox/220.127.116.11pre verified 18.104.22.168 Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1b2) Gecko/20060825 BonEcho/2.0b2 verified 1.8.1b2