Closed
Bug 546930
Opened 14 years ago
Closed 7 years ago
XMLHttpRequest sync send throws generic NS_ERROR_FAILURE on cross-site request
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: brille1, Unassigned)
Details
(Whiteboard: [dupeme])
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2) Gecko/20100115 Firefox/3.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2) Gecko/20100115 Firefox/3.6 Hi, I've just been testing around with a tiny JavaScript XMLHttpRequest script. While I can access an online web page from my local web page in IE8 I can't do this in Firefox. Sure, it's arguable if accessing an online resource from a local file may be a violation of the Same Origin policy. However, "undefined" seems the wrong error message to me. I suggest to either use error codes/messages from "http://www.w3.org/TR/XMLHttpRequest/#exceptions" or to give some other meaningful error message that can be presented to the user. Reproducible: Always Steps to Reproduce: 1. Create a local HTML file contaning JavaScript code to send an XMLHttpRequest. 2. Use a "http:" URL as the url parameter of the XMLHttpRequest::send() method. 3. Open the local HTML file and have the JavaScript code execute. Actual Results: Firefox throws an exception with error.Number==undefined and error.Message==undefined. Expected Results: Firefox should either not throw an exception or give a more meaningful exception number/message.
Updated•14 years ago
|
Product: Firefox → Core
QA Contact: general → general
Comment 1•14 years ago
|
||
You are breaking the same origin policy, so nothing you do will make this work. I think this method is killing the request becasue it breaks the same origin policy: 'nsXMLHttpRequest::CheckMayLoad' http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsXMLHttpRequest.cpp#1548
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
Comment 2•14 years ago
|
||
Setting back to unconfirmed and ccing jst to see if this is a bug. Reporter: can you attach your test case? Also, this may be a duplicate bug.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Whiteboard: [dupeme]
Yes, but no matter whether the code violates the Same Origin policy - throwing "undefined - undefined" is not a feasible solution. Please read my suggestion above. That's the main issue here.
Comment 4•14 years ago
|
||
We don't throw "undefined - undefined". But note that exceptions don't have properties named "Number" or "Message"... Which is why it would be good to attach a testcase; I'd like to see what exactly you're doing with the security exception that's thrown.
Comment 6•14 years ago
|
||
See comment 4. I have no idea why you think exceptions should have "Number" or "Message" properties. Note that per ECMAScript spec the only properties you can expect on an exception are "name" and "message". All other properties are extensions to the language.
Updated•14 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → INVALID
Hmmm... Visual Studio's IntelliSense provided me with these property names. So I didn't doubt these were correct... I'm sorry for that. I thought these were the correct property names of the Error class.
But nonetheless, the exception thrown is still a general one not giving any hint about the cause for the exception. Does Firefox only throw this single exception?
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Comment 9•14 years ago
|
||
No, but in this case there is no good exception to return. It's a sync load, and the exact cause of the load failure is not known by the time the method needs to return. See http://hg.mozilla.org/mozilla-central/annotate/77dab2533801/content/base/src/nsXMLHttpRequest.cpp#l2661 Over to DOM Extensions, and resummarizing, I guess. But my gut feeling is that trying to rearchitect the code around this isn't worth it.
Component: General → DOM: Mozilla Extensions
QA Contact: general → general
Summary: XMLHttpRequest send method throws "undefined" error when accessing web page from local file → XMLHttpRequest sync send throws generic NS_ERROR_FAILURE on cross-site request
Reporter | ||
Comment 10•14 years ago
|
||
Thanks for providing me with the source. Is there a way to get the source file without annotations and without much ado? I can't read the code having this style of parenthesis.
Component: DOM: Mozilla Extensions → General
Comment 11•14 years ago
|
||
Yeah, you can click the "raw" link at the top of the page linked to in comment 9.
Component: General → DOM: Mozilla Extensions
Reporter | ||
Comment 12•14 years ago
|
||
Strange... If I open the raw version, I still get a version having annotations preceding every line. So I can't open it in any C++ editor: This is what I get: hg@mozilla.com@1: /* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- */ hg@mozilla.com@1: /* ***** BEGIN LICENSE BLOCK ***** hg@mozilla.com@1: * Version: MPL 1.1/GPL 2.0/LGPL 2.1 hg@mozilla.com@1: *
Component: DOM: Mozilla Extensions → General
Comment 13•14 years ago
|
||
Ah, indeed. That gives the raw annotate output. You want to click "file" first, then "raw": http://hg.mozilla.org/mozilla-central/raw-file/77dab2533801/content/base/src/nsXMLHttpRequest.cpp Please stop setting the component back to the wrong one.
Component: General → DOM: Mozilla Extensions
Reporter | ||
Comment 14•14 years ago
|
||
Component?? I didn't do anything particular by intention... Thanks for pointing me. For today it's too late for me to have a look. I'll look at it this morning.
Component: DOM: Mozilla Extensions → General
Comment 15•14 years ago
|
||
> Component?? I didn't do anything particular by intention...
See the "history" link for this bug. Every time you comment, you're changing the component. Presumably because you're reloading the page but not force-reloading it (which preserves form control values).
Component: General → DOM: Mozilla Extensions
Reporter | ||
Comment 16•14 years ago
|
||
After looking at the code (without debugging), here's is my analysis: I don't see a reason why the code executes flawlessly and completely until finally some hard-coded return value is returned. This hard-coded return value should only be the last resort if no specific error reason could be obtained. But in this case there is a specific error reason. It's queried at: http://hg.mozilla.org/mozilla-central/annotate/77dab2533801/content/base/src/nsXMLHttpRequest.cpp#l2486 So at this stage any further processing becomes unnecessary and the return value should be set appropriately to a meaningful result.
Comment 17•14 years ago
|
||
CheckChannelForCrossSiteRequest returns success in this case. What it does is install filters that perform preflight requests, look at the response to decide whether to proceed with the actual XHR, etc, etc.
Reporter | ||
Comment 18•14 years ago
|
||
OK, so where's the code that's failing? And why does this function have a name different from what it does then?
Comment 19•14 years ago
|
||
> OK, so where's the code that's failing? I don't know offhand. Jonas might; that's why I cced him. > And why does this function have a name different from what it does then Er.. it does check the channel for a cross-site request. It just doesn't fail the load if it detects such a request; instead it installs the filters I mention in comment 17. I don't know what about the name said "I will make the load fail" to you.
Reporter | ||
Comment 20•14 years ago
|
||
Thanks, Boris! Well, for the function name: It's the part "check" in the name which I immediately link with a result. Someone usually checks something to get a result. If this function doesn't return a result, it doesn't pretend to check anything. I've never seen anyone saying: "I'm going to check for us if the train's coming late..." And later if being asked: "So?" - "Yep, I've checked it."
Reporter | ||
Comment 21•14 years ago
|
||
Sorry for mis-typing: The second paragraph should have read: "If this function doesn't return a result, it shouldn't pretend to check anything."
Reporter | ||
Comment 22•14 years ago
|
||
Instead, it should be called something like "CreateFiltersForCrossSiteRequest"
Comment 23•12 years ago
|
||
I'm getting org.junit.ComparisonFailure: e "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE)" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: http://localhost:12345/ :: test :: line 8" data: no for a CORS request when the server is returning Access-Control-Allow-Origin: <specific correct origin> with what I think is the correct origin in the request.
Comment 24•12 years ago
|
||
oops, please ignore my comment.
Reporter | ||
Comment 25•12 years ago
|
||
Problem still exists today.
Assignee | ||
Updated•11 years ago
|
Component: DOM: Mozilla Extensions → DOM
Comment 26•7 years ago
|
||
It throws a NetworkError these days which is correct per the XMLHttpRequest standard.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago → 7 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•