237606 - Accessing XMLHttpRequest "channel" attribute throws "Permission denied" exception

Status: RESOLVED WONTFIX

(Core :: XML, defect)

Description

[Chuck Musser]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040309 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040309 Firefox/0.8.0+

I'm trying to access an XMLHttpRequest attribute when executing one of its event
handlers, but the attribute is only available if the request is synchronous.

XMLHttpRequest's two event handlers--onload () and onerror()--are presented with
a single argument of type "Event". The event's target is the XMLHttpRequest
object. That object in turn has a "channel" field--an nsIChannel that can be
QI'ed to an nsIRequest. The ultimate goal is to access the a field in this
interface, "status", that contains network-related status of the request.

The problem is that the "channel" attribute of the XMLHttpRequest is available
if the XMLHttpRequest is synchronous, but not if it is asynchronous. In the
latter case, accessing this field results in this message in the Javascript console:

Error: [Exception... "'Permission denied to get property XMLHttpRequest.channel'
when calling method: [nsIDOMEventListener::handleEvent]"  nsresult: "0x8057001e
(NS_ERROR_XPC_JS_THREW_STRING)"  location: "<unknown>"  data: no]

Reproducible: Always
Steps to Reproduce:
1. Load the attached HTML page from a file:// URL so that you don't violate the
cross domain policy while testing.
2. Open the Javascript console so you can see exceptions as they happen.
3. Try an invalid URL in asynchronous mode.

Actual Results:  
Nothing will change in the browser window, but the Javascript console will show
an exception. For a valid URL, you'll get the same exception, but the request
will complete and the response will be displayed at the bottom of the page.

Expected Results:  
For both valid and invalid requests, the onload and onerror handlers should have
access to the channel.status attribute so they can display the error in the
browser window.

Tested in Firefox 0.8+ nightlies on both Mac OS X and Linux/GTK

Comment 1

[Chuck Musser]

Attachment: testcase

Comment 2

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Wouldn't XMLHttpRequest.status member give you what you want, without going to
the channel member?

(This bug might still be valid, regardless.)

Comment 3

[Chuck Musser]

Ah, I should have clarified what kind of errors I'm talking about. 

AFAIK, the XMLHttpRequest.status attribute you mention only contains HTTP status
codes: 200, 404, etc.

I'm interested in lower-level networking errors such as "host not found", "host
unreachable", and "connection refused". The only place I've been able to find
this is the "status" attribute contained in  XMLHttpRequest.channel.

Comment 4

[Johnny Stenback (:jst)]

XMLHttpRequest.channel is intentionally not scriptable by webpages since it's
our internal networking objects that we have no interest in exposing to web
pages. If a mechanism for obtaining more information about the error than what
XMLHttpRequest provides, then we need to do that on a different level, like
maybe as a new property of the error object that's passed to the error handler,
or something like that. Feel free to file a new bug on that if you feel it's
worth doing.

This bug is WONTFIX.

Comment 5

[Chuck Musser]

Sounds reasonable. From an application person's perspective, something more
intuitive than digging into the channel member would be preferable anyway. I do
think that the extra error information would help people write better
applications, so I'll write a new, more appropriate bug.

I don't understand the security ramifications, but I do have one comment: access
to the channel member is allowed for synchronous requests, but disallowed for
asynchronous ones. If there's a security concern, it seems like access should be
disallowed for both request types. Let me know if this warrants a separate bug.

Comment 6

[Johnny Stenback (:jst)]

There's no difference from a security point of view between async and sync
connections, the difference is only in how you write the code to enable access
to XPConnect in the two cases.

Maybe you don't fully know what you're doing in this testcase. You enable
"UniversalXPConnect" privileges in this testcase (the fact that your code works
differently in the async vs sync case is simply a matter of where you request
"UniversalXPConnect" privileges, try putting that code in the onerror handler
and see what happens), and that will give you access to *anything* on the
clients computer, if he grants your script those privileges. You can read any
file, you can write any file, run any programs. There are no limits.

The channel property of an XMLHttpRequest object might not on its own be a
security sensitive property, but it's Mozilla only thing, and it exposes Mozilla
internals that were never meant to be used by script on a webpage. And we can't
globally give access to our nsIChannel implementations, since with those you can
open connections to servers etc, and we don't want to deal with any of the risks
involved in opening that up.

So I say again, if you feel that the error messages you're trying to expose here
are general enough and you think they would be useful in more than a handful of
cases, and while being aware that such a feature would be Mozilla only, and not
available in any other browsers for some time at least, then by all means file a
new bug requesting such a feature on XMLHttpRequest. But I wouldn't expect we'll
ever expose our channel implementations to webpage scripts.

Comment 7

[Chuck Musser]

1.) I plead not guilty to ever actually *wanting* to use nsIChannel or it's
status attribute. It was the only place I could find the damn network errors. 

2.) No, I did not understand the implications of granting UniversalXPConnect
privileges. I appreciate your comments here and in in bug 238731. Sorry about
the invalid testcases.

3.) I did file bug 238559 to request that XMLHttpRequest provide network error
status.