Closed Bug 331825 Opened 19 years ago Closed 18 years ago

Unable to do conditional gets via XMLHttpRequest with 1.5.0.1, works in 1.0.7

Categories

(Core :: Networking: HTTP, defect)

1.8 Branch
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla1.8.1

People

(Reporter: yusufg, Assigned: darin.moz)

References

()

Details

(Keywords: regression, verified1.8.0.7, verified1.8.1)

Attachments

(2 files, 1 obsolete file)

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 1.5.0.1 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
Flags: blocking1.8.1?
Flags: blocking1.8.0.5?
> 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
Flags: blocking1.9a2?
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!
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 1.8.0.5, but it's not going to write itself assigned to nobody@mozilla.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.
Assignee: nobody → darin
Flags: blocking1.8.0.5? → blocking1.8.0.5-
Darin - any thoughts on what the right fix is here?
Flags: blocking1.8.1? → blocking1.8.1+
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.
Attached patch v1 patch (obsolete) — Splinter Review
Attachment #226581 - Flags: superreview?(bzbarsky)
Attachment #226581 - Flags: review?(cbiesinger)
Attachment #226581 - Flags: superreview?(bzbarsky) → superreview+
Attached patch v1.1 patchSplinter Review
Here's a slightly better variant on the same patch that biesi suggested.
Attachment #226581 - Attachment is obsolete: true
Attachment #226714 - Flags: review?(cbiesinger)
Attachment #226581 - Flags: review?(cbiesinger)
Attachment #226714 - Flags: review?(cbiesinger) → review+
fixed-on-trunk
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Attachment #226714 - Flags: approval1.8.1?
Attachment #226714 - Flags: approval1.8.1? → approval1.8.1+
What effects (if any) might this have on stuff other than XMLHttpRequest?
fixed1.8.1
Keywords: fixed1.8.1
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: approval1.8.0.6?
Comment on attachment 226714 [details] [diff] [review] v1.1 patch approved for 1.8.0 branch, a=dveditz for drivers
Attachment #226714 - Flags: approval1.8.0.7? → approval1.8.0.7+
Grr.. the patch did not apply cleanly to the 1.8.0 branch :-(
fixed1.8.0.7
Keywords: fixed1.8.0.7
using testcase described in comment #0 Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7pre) Gecko/20060825 Firefox/1.5.0.7pre verified 1.5.0.7 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
Flags: blocking1.9a2?
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: