Re: XMLHttpRequest error events

> for security reasons cross-origin fetches would not be able to provide 
> these diagnostics 
In that case, the error event should report "Forbidden by cross-origin 
policy".   At least that gives a clue - we know it's not a DNS failure 
or an unplugged cable or...  In this case, not directly useful to the 
end-user, but when (s)he reports it to the help desk, the person they 
escalate it to will have a place to start.  And a developer will 
(should) know what to do when his testing(?) encounters the problem.

Hiding the failure cause does nothing to improve security, rather it 
makes diagnosing issues and writing good code harder.  As such, it's 
more likely to cause people to write overly permissive code 'to get it 
working'.   The bad guys know what rule they're trying to break.  So the 
current behavior really only hurts the good gusy.

On 10-Feb-14 12:16, Nick Krempel wrote:
> 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 
> <mailto: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.
>
>
>
>


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