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

VERIFIED FIXED in mozilla1.8.1

Status

()

Core
Networking: HTTP
VERIFIED FIXED
11 years ago
10 years ago

People

(Reporter: Yusuf Goolamabbas, Assigned: Darin Fisher)

Tracking

({regression, verified1.8.0.7, verified1.8.1})

1.8 Branch
mozilla1.8.1
regression, verified1.8.0.7, verified1.8.1
Points:
---
Bug Flags:
blocking1.8.1 +
blocking1.8.0.5 -
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

11 years ago
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.
(Reporter)

Updated

11 years ago
Target Milestone: mozilla1.8final → mozilla1.8.1
(Reporter)

Comment 1

11 years ago
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
(Reporter)

Comment 2

11 years ago
sorry for bugspam, really meant networking:cache
Component: Networking: HTTP → Networking: Cache
(Reporter)

Comment 3

11 years ago
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
(Assignee)

Comment 5

11 years ago
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!

Comment 7

11 years ago
Look for HTTP cache in http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/publish/XMLHttpRequest.html#dfn-send

Please send comments to public-webapi@w3.org.
(Assignee)

Comment 8

11 years ago
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-

Comment 11

11 years ago
Darin - any thoughts on what the right fix is here?
Flags: blocking1.8.1? → blocking1.8.1+

Comment 12

11 years ago
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.
(Assignee)

Comment 13

11 years ago
I can reproduce the behavior difference  FF1.0 and FF1.5.  I'm investigating to see what changed.
(Assignee)

Comment 14

11 years ago
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.
(Assignee)

Comment 15

11 years ago
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.
(Assignee)

Comment 16

11 years ago
Created attachment 226581 [details] [diff] [review]
v1 patch
Attachment #226581 - Flags: superreview?(bzbarsky)
Attachment #226581 - Flags: review?(cbiesinger)
(Assignee)

Comment 17

11 years ago
Created attachment 226583 [details] [diff] [review]
corresponding regression test
Attachment #226581 - Flags: superreview?(bzbarsky) → superreview+
(Assignee)

Comment 18

11 years ago
Created attachment 226714 [details] [diff] [review]
v1.1 patch

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+
(Assignee)

Comment 19

11 years ago
fixed-on-trunk
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
(Assignee)

Updated

11 years ago
Attachment #226714 - Flags: approval1.8.1?

Updated

11 years ago
Attachment #226714 - Flags: approval1.8.1? → approval1.8.1+
What effects (if any) might this have on stuff other than XMLHttpRequest?
(Assignee)

Comment 21

11 years ago
fixed1.8.1
Keywords: fixed1.8.1
(Assignee)

Comment 22

11 years ago
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+
(Assignee)

Comment 24

11 years ago
Grr.. the patch did not apply cleanly to the 1.8.0 branch :-(
(Assignee)

Comment 25

11 years ago
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
Keywords: fixed1.8.0.7, fixed1.8.1 → verified1.8.0.7, verified1.8.1
Flags: blocking1.9a2?

Updated

10 years ago
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.