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:
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.
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
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.
Created attachment 148157 [details] [diff] [review] 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.
This would be nice indeed.
12 years ago
12 years ago
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>
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?
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.
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.