This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently browsers (Opera, Firefox, Chromium) reconnect when they loose their connection. Opera only tries a few times and a very short time, whilst Firefox retries for around 15 minutes before giving up. Chromium keeps it going indefinitely. They do an exponential increase of the wait time. Up to a max. A smarter implementation would also listen to "network up" events from the OS etc. Second discussion: [2] http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0399.html (Something wrong with archive, so here is the rest of the thread:) [3] http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/thread.html#msg82 First discussion: [1] http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0226.html As discussed in the email threads ([3],and in [1]), it would also make sense to notify of this state. In that way authors will be able to handle the reconnect on their own if they want: es.onreconnecting = function(e) { // es.readyState is EventSource.RECONNECTING // We don't want the default behaviour es.close(); do_custom_reconnecting_logic(); };
Summarising the comments from the discussions: At the moment, the spec states that "any network error that prevents the HTTP connection from being established in the first place (e.g. DNS errors), must cause the user agent to fail the connection." This means that in the event of network loss, the UA will try to reconnect once (probably 30 seconds after the initial network loss dropped the connection to the server), then fail permanently if the network is still unavailable at the time of reconnection. I can't see any use case where you *wouldn't* want to reconnect again after network loss, so by prohibiting this in the spec, you're forcing developers to continually re-implement the same behaviour, but with less information available to them than the UA has. UAs are better place to handle reconnection after network loss, as they have access to OS-level network connectivity information so can trigger a reconnect as soon as the device regains network access. Most web developers will find the currently specified behaviour unintuitive (in fact most probably won't even realise and thus applications will break on network loss), and most UAs are currently ignoring the spec in this area. To resolve this, the spec should be changed to require the EventSource object to enter a reconnecting state on network loss, connecting again immediately after the UA detects network connectivity has been regained, or if this information is not available, retrying connection at exponentially increasing intervals (subject to a maximum interval of, say, 5 minutes).
*** This bug has been marked as a duplicate of bug 15495 ***