- From: <bugzilla@jessica.w3.org>
- Date: Thu, 19 Jul 2012 08:11:34 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18320 Neil Jenkins <neilj@opera.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |neilj@opera.com --- Comment #1 from Neil Jenkins <neilj@opera.com> 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). -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Thursday, 19 July 2012 08:11:38 UTC