Bug 18320 - Clarify how reconnection works after losing internet connectivity
Summary: Clarify how reconnection works after losing internet connectivity
Status: RESOLVED DUPLICATE of bug 15495
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: Server-Sent Events (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P2 blocker
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-18 22:30 UTC by Odin Hørthe Omdal
Modified: 2012-08-07 18:03 UTC (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Odin Hørthe Omdal 2012-07-18 22:30:48 UTC
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();
     };
Comment 1 Neil Jenkins 2012-07-19 08:11:33 UTC
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).
Comment 2 Ian 'Hixie' Hickson 2012-08-07 18:03:12 UTC

*** This bug has been marked as a duplicate of bug 15495 ***