Regards,
Philip Withnall (bug triager)
> I was wondering what the official response was to bug #331610
> (https://bugzilla.mozilla.org/show_bug.cgi?id=331610): a guy's tried
> using XMLHttpRequest with a non-HTTP protocol (in this case, "file://"),
> and has found that the status codes are different to HTTP. Is this
> intentional, or a bug?
Mozilla's implementation of XMLHttpRequest follows the implementation
that Microsoft has done in MSXML for IXMLHttpRequest and that, for file:
URLs, returns the status as 0. If you see that then I think it is
intentional.
--
Martin Honnen
http://JavaScript.FAQTs.com/
> Apparently (I haven't tested it; I'm just going on what the bug reporter
> has just written) IE returns a status 200 for successfully loaded local
> files.
No, IE (at least IE 5, 5.5, 6) uses MSXML as an ActiveXObject and that
returns status as the number 0 for successful file: URL requests with
MSXML 2.6, 3, 4, 5, 6 in my tests here.
Opera 8 and Opera 9 preview also return 0 as the status code for file:
URL access.
I think there would be a case for returning HTTP status codes for
> any file loaded with XMLHttpRequest:
> - It is XML*Http*Request (so the use of HTTP standards would follow in
> the interface)
If the name part is to be used as an argument then you could as well
argue that file: URL access has to be removed completely as file: URL
access does not use the HTTP protocol.
As I said, you could argue it both ways, but I've since been shown that
the name argument was not a particularly good route to go down.
Regardless, the bug's been resolved as invalid (again).