Ah wait, when loading files locally with xmlhttprequest, you don't get a status returned probably, because you're not on a webserver.
(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://.
(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.
I've asked on news.mozilla.org, and I believe this is intentional.
(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.
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
(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.
Created attachment 216422 [details] 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.
Hmm, IE returns 0 as well for me.
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.
I had a similar experience (FireFox 18.104.22.168), 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