238559 - XMLHttpRequest needs a way to report networking errors

Status: RESOLVED WORKSFORME

(Core :: XML, enhancement)

Description

[Chuck Musser]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

Currently, the only types of errors XMLHttpRequest can report are HTTP errors,
via the "status" attribute. There is no way to consistently get status on
requests that fail because the server host is down, the server refuses the
request or the hostname is unresolvable.

There is a way to get this information some of the time: if you set an onerror
handler for an synchronous request (yes this is sort of contradictory) you can
access the XMLHttpRequest object's "channel" attribute, QI it to an nsIRequest
and find out what happened from that interface's status. This is sort of arduous
and in any case, it doesn't work for asynchronous requests: accessing the
"channel" attribute results in a "Permission denied" exception. The resolution
for bug 237606 indicates that this is the proper behavior, due to security concerns.

Some possible ways of making this error information available:

1.) Add a field to the event object that gets passed to the onload and onerror
handlers. This seems kind of crummy because that object seems more suited toward
GUI and DOM events. Not sure if there's an existing field that would be ppropriate.

2.) Add a field to XmlHttpRequest. This is intuitive, but it's not in the
version of XMLHttpRequest provided by That Other Browser(tm). I've not yet
investigated how IE handles network errors and I don't know how important
compatibility is with the Msxml2.XMLHTTP object.

Any thoughts?

Reproducible: Always
Steps to Reproduce:

Comment 1

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

I seem to remember discussing this with the WSDL developers and recall that
there was a solution. You should check the Web Services code to see if there is
any mention about this. I think you needed to check 2-3 things to find out that
a network error occurred. Disclaimer: I could remember wrong.

Also, there are some test cases in
http://lxr.mozilla.org/seamonkey/source/extensions/xmlextras/tests/ that do some
testing with network errors - see badhostsyncget.html and 404post.html.

If you can access the channel attribute, it is a bug. Please file a bug with a
testcase.

We should strive for compatibility as much as possible.

Comment 2

[Chuck Musser]

The Mozilla and IE XMLHttpRequest implementations differ in how they handle
events and present status. Here's a rundown of the differences and some
observations:

1.) The Microsoft.XMLHTTP object doesn't have separate onload and onerror event
handlers. You're supposed to use the onreadystatechange handler to be notified
when the request is "loaded," which could mean that it simply failed. You can
probably write code that would work on both platforms.

2.) With IE, the status attribute can contain HTTP status codes OR
networking-related error codes. These codes are documented here: 
 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winhttp/http/error_messages.asp

Is there a disadvantage to doing it this way? I'd like to see the errors codes
in http://lxr.mozilla.org/seamonkey/source/netwerk/base/public/nsNetError.h
If statusText contained the correct text (e.g. "Connection refused"), that would
be helpful too. IE doesn't do this for the network errors, BTW--statusText
contains "Unknown" in those cases.

3.) Mozilla calls onload() for all HTTP transactions that succeeded. The only
time it calls onerror() is when a network error happened. Inside the onerror
handler, accessing the status attribute results in this exception:

Error: [Exception... "Component returned failure code: 0x80040111
(NS_ERROR_NOT_AVAILABLE) [nsIXMLHttpRequest.status]"  nsresult: "0x80040111
(NS_ERROR_NOT_AVAILABLE)"  location: "JS frame ::
file:///Users/chuck/errtest.html :: anonymous :: line 114"  data: no]
Source File: file:///Users/chuck/errtest.html
Line: 114

Comment 3

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

We should provide the same numeric errors as IE does in status. I think it would
be ok to provide a sensible statusText instead of unknown, but up to you.

Accessing status inside onerror handler throws because HTTP channel throws:
http://lxr.mozilla.org/seamonkey/source/extensions/xmlextras/base/src/nsXMLHttpRequest.cpp#592
We could be smarter here, and return whatever is the correct status value in
case HTTP channel says not available.

Comment 4

[Chuck Musser]

Attachment: preliminary patch to return networking errors in status and statusText

I've looked into Mozilla's and IE's error handling. Emulating IE's behavior 
would require a lot of research and testing, and the end result doesn't look
very good.

The detailed rationale is below, but my suggestion is that non-HTTP
values in "status" and "statusText" be interpreted as "the error code from the 

underlying networking engine". For Mozilla, this means we simply call
httpChannel->GetStatus() whenever calling httpChannel->GetResponseStatus()
(or httpChannel->GetResponseStatusText()) returns NS_ERROR_NOT_AVAILABLE.

I've attached a preliminary patch that does this for the "status" and
"statusText" members. Notes on the patch:

1.) GetStatusText() doesn't have text strings for every error listed in
    nsNetError.h. I only included the most commonly encountered ones to
    demonstrate the approach.

2.) It doesn't put a text string into the exception thrown by "open()".
    The exception already contains the correct error code, but I haven't
    figured out how to add the text string yet.

Heikki, this proposal runs counter to your earlier suggestion. Let me know 
what you think about these findings:

1.) IE's WinHTTP has 50 errors and Mozilla's nsNetError.h has 38. I've found
    only eight that correlate directly and have only confirmed six of those.
    The non-matching codes fall into these categories:

    1.) Implementation specific codes like WinHTTP's "out of handles" or
    Necko's NS_BINDING_RETARGETED. Necko doesn't have that many of these
    so they aren't much of a problem.

    2.) Errors that sound similar but neither implementation produces. I 
    haven't been able to produce a NS_ERROR_NET_TIMEOUT (Necko) or 
    WINHTTP_ERROR_TIMEOUT in my testing

    3.) Classes of errors that one implementation returns but the other
    doesn't. WinHTTP defines lots of errors related to certificates, but
    Necko doesn't, at least not in nsNetError.h. Necko has errors for
    cache-related problems and FTP connection errors, but WinHTTP doesn't.

    You can see where I'm going with this: matching up these errors is a
    real chore.

2.) IE reports "host not found" and "proxy host not found" as the same error.
    Same with "connection refused" and "connection to proxy refused." I'd like
    to see Mozilla provide _specific_ error information, rather than lump 
    similar failures together. Necko already provides separate error codes
    for these cases.
    
3.) IE does not report usable error information in the case of malformed URIs
    and unknown URI schemes. Mozilla's behavior for these cases is simple: the
    "open()" method throws an exception, storing the error code in the 
    exception object's "result" member. This is reasonable. IE's behavior, in
    contrast, is complicated and weird:

    For unknown schemes, the open() method throws no error, but the send() 
    method does. The exception object contains an "OK" status, which is 
    obviously not the case.

    For malformed URIs, IE again throws an exception during send(), then sets
    the status member to 87, a value not documented in the WinHTTP error codes
    page.

Comment 5

[Stelian Pop]

This would be nice indeed.

Comment 6

[Arnaud Diederen]

Hello all,

we're using the YUI connection manager, and we keep having "network failures".

Using wireshark, we could notice that the XMLHttpRequest typically fails when the data that's being sent to it is in "Transfer-Encoding: chunked", *and* the server is behind a Apache AJP proxy. It seems the AJP proxy is removing the chunked "chunk size" information (i.e., the hex-encoded size line, that is present before every chunk)!

However, if we switch the proxy to the HTTP type, the XMLHttpRequest's succeed.
We're using versions of FireFox 3.5.0+

Has anyone experienced the same type of issues?

Thanks for any hint!
          Arnaud

Just FYI: Here's our apache configuration:

** Apache Version: 

antares:~# dpkg -l|grep apache
ii  apache2                           2.2.9-10+lenny6            Apache
HTTP Server metapackage
ii  apache2-mpm-prefork               2.2.9-10+lenny6            Apache
HTTP Server - traditional non-threade
ii  apache2-utils                     2.2.9-10+lenny6            utility
programs for webservers
ii  apache2.2-common                  2.2.9-10+lenny6            Apache
HTTP Server common files
ii  libapache2-mod-jk                 1:1.2.26-2+lenny1          Apache
2 connector for the Tomcat Java servl
rc  libapache2-mod-php4               6:4.4.4-8+etch6
server-side, HTML-embedded scripting languag
ii  libapache2-mod-php5               5.2.6.dfsg.1-1+lenny4
server-side, HTML-embedded scripting languag

** This configuration works: 
<Proxy *>
AddDefaultCharset off
Order deny,allow
Deny from all
</Proxy>
# Enable/disable the handling of HTTP/1.1 "Via:" headers.
# ("Full" adds the server version; "Block" removes all outgoing Via:
headers)
# Set to one of: Off | On | Full | Block
ProxyVia On

ProxyPreserveHost On
<Location /hira-client>
ProxyPass http://achernar:8080/hira-client
ProxyPassReverse http://achernar:8080/hira-client
Order deny,allow
Allow from all
</Location>

** This configuration doesn't work (i.e., the chunked encoding will miss some information)

<Proxy *>
AddDefaultCharset off
Order deny,allow
Deny from all
</Proxy>
# Enable/disable the handling of HTTP/1.1 "Via:" headers.
# ("Full" adds the server version; "Block" removes all outgoing Via:
headers)
# Set to one of: Off | On | Full | Block
ProxyVia On

ProxyPreserveHost On
<Location /hira-client>
ProxyPass ajp://achernar:8009/hira-client
ProxyPassReverse ajp://achernar:8009/hira-client
Order deny,allow
Allow from all
</Location>

Comment 7

[alex_mayorga]

Loading http://new.music.yahoo.com/ricardo-arjona/videos/view/vida--218722949 shows a gray box instead of the actual video and the errors below appear on the "Error Console" using Mozilla/5.0 (Windows NT 6.0; rv:2.0b8pre) Gecko/20101118 Firefox/4.0b8pre ID:20101118112142

Error: uncaught exception: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIDOMHTMLDocument.createElementNS]"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: http://l.yimg.com/p/js/compressed/music_global_bottom_1.9.2.js :: <TOP_LEVEL> :: line 1"  data: no]
Error: YAHOO.music.search is undefined
Source File: http://new.music.yahoo.com/ricardo-arjona/videos/view/vida--218722949
Line: 532
Error: SWFObject is not a constructor
Source File: http://l.yimg.com/p/combo?music/d/js/1288984039/Yahoo.Music.Video.AddToPlaylist.js&music/d/js/1288984039/Yahoo.Music.Video.Evp.js&music/d/js/1288984039/carousel.js&music/d/js/1288984039/carousel_ajax.js&music/d/js/1288984039/moreVideos.js
Line: 726

Am I seeing this bug or a different one?

Comment 8

[Helder "Lthere" Magalhães]

(In reply to comment #7)
(Slightly reordered to help replying.)


> Am I seeing this bug or a different one?

A completely different one - notes follow.


> Error: uncaught exception: [Exception... "Component returned failure code:
> 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIDOMHTMLDocument.createElementNS]" 
> nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame ::
> http://l.yimg.com/p/js/compressed/music_global_bottom_1.9.2.js :: <TOP_LEVEL>
> :: line 1"  data: no]

This is a DOM error. JavaScript is trying to invoke "createElementNS" in an element which doesn't support it and/or which may not be ready yet. Please contact the site webmaster and/or script library developer (apparently "Yahoo!").


> Error: YAHOO.music.search is undefined
> Source File:
> http://new.music.yahoo.com/ricardo-arjona/videos/view/vida--218722949
> Line: 532

This is a JS error. A variable is broken/missing/undefined, which triggers this JavaScript "namespace"-like error. Please contact the site webmaster and/or script library developer (apparently "Yahoo!").


> Error: SWFObject is not a constructor
> Source File:
> http://l.yimg.com/p/combo?music/d/js/1288984039/Yahoo.Music.Video.AddToPlaylist.js&music/d/js/1288984039/Yahoo.Music.Video.Evp.js&music/d/js/1288984039/carousel.js&music/d/js/1288984039/carousel_ajax.js&music/d/js/1288984039/moreVideos.js
> Line: 726

This is a JS error. Some JavaScript error prevented the variable "SWFObject" to be properly created. Please contact the site webmaster and/or script library developer (apparently "Yahoo!").


So, all issues are unrelated to XMLHTTPRequest not having a way to report networking errors. ;-)

Comment 9

[Davit Barbakadze]

Has this request ever been addressed? In my test case (on FF 7.0.1) XMLHTTPRequest fails to report 408timeout error with it's status/statusText properties. They contain correspondingly 0 and "" (empty string) after error has been detected. I observe this through FireBug console. Other errors (like 404) are reported as expected.

Comment 10

[Thomas Wisniewski]

At this point I don't think this is a general issue anymore. XHRs report status/statusText codes (including lesser-used ones like 408), onerror/onabort/ontimeout are fired when appropriate, onerror provides generally-useful exception details (though still not always the same exceptions that the XHR spec dictates), and even CORS failures can be inferred programmatically (and are logged in the web console).
 
Hence I think this bug can be closed, and I would suggest filing more specific bugs if the current state of networking error reporting isn't sufficient for certain use-cases.