331610 - XMLHttpRequest.status is 0 (not 200) for local file:// resources

Status: RESOLVED INVALID

(Core :: XML, defect)

Description

[Douglas Campbell]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.0.1) Gecko/20060124 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.0.1) Gecko/20060124 Firefox/1.5.0.1

AJAX javascript code changes a DIV element and should upload text to insert in the DIV element (replacing existing text).  The code does not work when the index.html file is opened using "open file"; it does work if the "open location" method of obtaining the index.html page is used.  In both cases, the initial webpage loads and looks identical; however, succeeding operations (which all involve file fetches and no server-side activity) fail in the "file://" case but succeed in the "http://" case.

Reproducible: Always

Steps to Reproduce:
1. Download AJAX for Dummies companion code from http://media.wiley.com/assets/1002/24/ajaxcode.zip
2. unzip the code into a directory accessible both via local filesystem and via httpd
3. using either mozilla or firefox, attempt to load file://<localfs_loc>/ch02/index.html
4. After page "Ajax at work" loads, click the "Display Message" button. Observe no changed text.
5. Using same browser as above, load "http://<host>/ch02/index.html
6. After page "Ajax at work" loads, click the "Display Message" button.  Observe one line of changed text. 

Actual Results:  
The page fails to change content:  the line "The fetched data goes here" should change to "This text was fetched using Ajax".

Expected Results:  
The page should change content.

Bug occurs with both firefox 1.5.0.1 and mozilla under Linux.  The browser does not crash, nor does the javascript console indicate any errors.  Removing spaces around the equal signs in index.html produces no change in behavior except in view-source.

Comment 1

[Martijn Wargers (dead)]

Attachment: File in question

This is the file in question.
I do get a javascript error in the console when clicking on the button:
"Error: syntax error
Source File: file:///C:/Documents%20and%20Settings/mw22/Bureaublad/ajaxcode/ch02/data.txt
Line: 1, Column: 1
Source Code:
This text was fetched using Ajax. "

When I remove the  && XMLHttpRequestObject.status == 200 check from the file, then the script works just fine.
IE6 works just fine, so it seems like a bug to me in Mozilla.

Comment 2

[Martijn Wargers (dead)]

Ah wait, when loading files locally with xmlhttprequest, you don't get a status returned probably, because you're not on a webserver.

Comment 3

[Douglas Campbell]

need file data.txt in same directory as index.html.  File should have a single line without tags reading:

This text was fetched using Ajax.

If the file data.txt is not present, a javascript error occurs.

Comment 4

[Douglas Campbell]

Martijn,

Sorry to make you fetch the file; if I ever have another issue I'll do it myself .

I interpret that you are stating that a status is not returned
if the file was fetched using a base href starting file:// whereas a status is returned if the file was fetched using http://

So from my uneducated (know nothing about Mozilla/Firefox internals) vantage, there are two possibilities:
a) The javascript in the example is wrong and should use alternate means of processing URLs beginning file://
or
b) The localized pseudo-webserver built into Mozilla for handling base URLs beginning file:// is broken and is not returning a status when it should.

(In reply to comment #2)
> Ah wait, when loading files locally with xmlhttprequest, you don't get a status
> returned probably, because you're not on a webserver.
> 

Comment 5

[Philip Withnall (unavailable)]

(In reply to comment #4)
> b) The localized pseudo-webserver built into Mozilla for handling base URLs
> beginning file:// is broken and is not returning a status when it should.
It's debatable that the file:// protocol handler should do that. It's not a web server; it's simply an interface to your local filesystem, just the same as ftp:// shouldn't return HTTP status codes.
I suggest that XMLHttpRequest should either work differently (i.e. no statuses, although I can't see the effectiveness of this) or not at all with protocols other than http://.

Comment 6

[Douglas Campbell]

(In reply to comment #5)

The status placed into the XMLHttpRequest object is 0 if it successfully loads a local file, but 200 if it successfully loads a webserved file.  Why different success states due only to URL content?

I replaced the code comparing status to 200 to a compound boolean comparing it to either 200 or 0; the code now works.  So there is a javascript workaround. I don't know how good it is until I figure out whether a webserver could return a zero status code as an unsuccessful status to a request.

And I didn't know the returned status was also zero for ftp:// GET requests.  This is getting interesting.

Comment 7

[Philip Withnall (unavailable)]

(In reply to comment #6)
> (In reply to comment #5)
> 
> The status placed into the XMLHttpRequest object is 0 if it successfully loads
> a local file, but 200 if it successfully loads a webserved file.  Why different
> success states due only to URL content?
> 
> And I didn't know the returned status was also zero for ftp:// GET requests. 
> This is getting interesting.
> 

Because they're using different protocols. You don't use HTTP for fetching local or FTP files, so any stuff related to HTTP when working with such files has to be hacked around.

Comment 8

[Philip Withnall (unavailable)]

I've asked on news.mozilla.org, and I believe this is intentional.

Comment 9

[Douglas Campbell]

(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
I thought XMLHTTPRequest was supposed to screen where stuff comes from in terms of protocol.  It actually makes no sense to differentiate where a page came from in terms of status, if the engine is going to treat the content identically in spite of origin.  Someone here posted that they had tested this under IE and IE returns a 200.  I realize that IE is the ENEMY in some sense, but every once in a while, IE gets it right, particularly when we have to add more code for no real gain doing it the Mozilla way, which reveals implementation details about where the page came from.  I'm impressed the way someone punted this by converting this to "RESOLVED INVALID".  I'm not going to start a war by clicking the "reopen bug" button, but I am going to say I'm pretty disappointed in you guys.  

The reason I opened this bug is because I have a course I give to 3rd and 4th graders at the local elementary school on HTML.  The paradigm is for each student to develop their "myspace" website locally using only the students' webbrowsers (which to date have been Netscape/Mozilla/Firefox), and then to post the completed work to the district website.  I decided this term to add AJAX to the mix.  Now I don't have the time to port the various AJAX frameworks I'm reviewing so they work locally under Gecko, and my kids certainly wouldn't understand how to do so at home after my class. IE gets the nod from hereon because I don't have to touch any AJAX framework to get it to work locally under IE.  I've graduated approximately 100 Netscape/Mozilla/Firefox 3rd and 4th graders each year for the past 10 years; many of these kids (now college age) had only seen IE and had no idea any other browser existed.  I'm sad for what I must now do, but I've got no choice.  Cheers.

Comment 10

[Philip Withnall (unavailable)]

Resolving a bug as invalid doesn't mean the matter's finished. In fact in hindsight, I think I might've done so prematurely.
For reference, the news.mozilla.org thread: http://groups.google.com/group/mozilla.dev.ajax/browse_thread/thread/0ffb0e899cd404ff/c02ece139b6eed9a#c02ece139b6eed9a

Comment 11

[Nickolay_Ponomarev]

(The referenced thread says that we try to follow the IE implementation, so if it returns 200, we probably should do that too.)

Resummarizing the bug according to comments 1 and 6.

By the way, the attached file is probably a wrong one, there's no mention of .status there.

Comment 12

[Martijn Wargers (dead)]

Attachment: File in question

Sorry, I must have removed it while testing. This is the original file.
For testing, you also need to have a data.txt file for testing.

Comment 13

[Nickolay_Ponomarev]

Hmm, IE returns 0 as well for me.

Comment 14

[Martijn Wargers (dead)]

Argh, I'm terribly sorry. I must have my testing mixed up (I must have tested with the wrong testcase in IE6).
IE6 now also returns 0 for me.
So I guess this bug is indeed invalid. Mozilla is already doing the same as IE6 here.

Comment 15

[Guru Prasanna]

I had a similar experience (FireFox 2.0.0.10), when tried with non-existent URL
e.g. http://localhost/nopage.php

FireFox displays unable to connect but XMLHttpRequest simple crashes (no errors in console, no exceptions raised) when tried to access property "status".

I've posted the code here:
http://forums.mozillazine.org/viewtopic.php?t=607266