This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 22381 - When the user agent reestablishes or fails the connection it would be useful to have some indication of the reason for failure. Consider that most applications will wish to inform their user of an [...]
Summary: When the user agent reestablishes or fails the connection it would be useful ...
Status: RESOLVED NEEDSINFO
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-16 02:29 UTC by contributor
Modified: 2013-07-02 22:33 UTC (History)
2 users (show)

See Also:

Attachments

Description contributor 2013-06-16 02:29:12 UTC 
Specification: http://www.w3.org/TR/eventsource/
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top
Referrer: 

Comment:
When the user agent reestablishes or fails the connection it would be useful
to have some indication of the reason for failure.

Consider that most applications will wish to inform their user of an error
rather than fail silently; if the best possible is "Connection failed for
unknown reason" this gives no hints to the user about how to solve the
problem.

For example the ability to report the difference between a Not Found error and
a connection timeout can inform users if they should check their own network
connection or contact the site administrator.

The fact that the user agent is supposed to attempt to reconnect is not alone
sufficient to let an error go unreported.  If someone's network cable falls
out it can attempt to reestablish forever, but it would be much more effective
to prompt the user to plug it back in.

While in theory this could be used to gather information about a network, such
is already available by making ordinary CORS requests (via XMLHttpRequest etc)

Posted from: 108.20.225.179
User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0
Comment 1 Ian 'Hixie' Hickson 2013-06-21 16:23:12 UTC 
Actually we don't provide any less information than you can get in other ways, as far as I can tell.

We can't, because leaking information about the network would, as you surmise, be a security problem, e.g. exposing intranet topology.

I've updated the spec to suggest that debugging info be provided in consoles, but I don't know if that helps your case.

Would you like the browser to tell the user what it knows about connection problems as well, somehow?