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)

x86_64
Windows 7
defect
Not set
normal

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.
Product: Firefox → Core
QA Contact: general → general
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
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.
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.
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.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago14 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 → ---
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
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
Yeah, you can click the "raw" link at the top of the page linked to in comment 9.
Component: General → DOM: Mozilla Extensions
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
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
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
> 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
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.
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.
OK, so where's the code that's failing? And why does this function have a name different from what it does then?
> 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.
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."
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."
Instead, it should be called something like "CreateFiltersForCrossSiteRequest"
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.
oops, please ignore my comment.
Problem still exists today.
Component: DOM: Mozilla Extensions → DOM
It throws a NetworkError these days which is correct per the XMLHttpRequest standard.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago7 years ago
Resolution: --- → WORKSFORME
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: