XMLHttpRequest error events

I found myself using XMLHttpRequest in an application where, when things 
go wrong, I wanted to provide information to the user.  I was unable to 
do so.

Specifically, I POSTed a form with a large file, and specified listeners 
for abort and error events (among others) on both the request and upload 
targets.  I tried disconnecting the network, shutting down the target 
webserver, mis-spelling the host name, having the server refuse service 
and injecting various other real-world misadventures.

Although I get the events in several browsers, nothing in the event 
tells me what went wrong.  And I find nothing in the specification ( 
http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html - 22-Nov-2013) to 
help.

According to the spec, in the synchronous model, the exception would at 
least specify 'NetworkError'.  Async, the only thing one gets is the 
event type, bytes transfered, and (possibly) total bytes.  One can 
assume if loaded is zero, no connection was established; otherwise there 
was a connection failure, but that's about it.

It really would be useful - both for debugging and for providing 
feedback to users - if the error and abort events provided some detail:
Was the problem:
    DNS failure: no server, host has no A(AAAA) record?
    Proxy not reachable?
    Host not reachable?
    SSL certificate expired?
    Connection broken?
    Aborted by user action?
    Aborted by object destruction?
Some supporting detail (e.g. IP address of peer, proxy, etc) would be 
helpful too.

This is not intended to be an exhaustive list.

While I would discourage client scripts from trying to analyze 
OS-specific error codes, some user-actionable clues would be really 
helpful.  'An error occurred sending <flilename>' is about the best one 
can do currently, and that doesn't give the user - or the helpdesk - 
much to go on!

Please consider updating the spec to provide reasonable diagnostics for 
network error events.

-- 
This communication may not represent my employer's views,
if any, on the matters discussed.

Received on Monday, 10 February 2014 14:26:38 UTC