Re: XMLHttpRequest error events

This sounds nice, but for security reasons cross-origin fetches would not
be able to provide these diagnostics unless the fetch got as far as passing
the CORS check.



On 10 February 2014 12:30, tlhackque <tlhackque@yahoo.com> wrote:

> 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.
>
>
>
>