- From: Neil Jenkins <neilj@opera.com>
- Date: Sun, 29 Apr 2012 01:52:12 +0100
- To: public-webapps@w3.org
- Cc: Odin Hørthe Omdal <odinho@opera.com>, Charles McCathieNevile <chaals@opera.com>
In response to the request for comments on server-sent events, I believe the definition of when to fail a connection needs clarification and/or adjustment. Specifically, in Section 5 Processing Model, the line: "Any other HTTP response code not listed here, and 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." Combined with the definition of "fail the connection"... "When a user agent is to fail the connection, the user agent must queue a task which, if the readyState attribute is set to a value other than CLOSED, sets the readyState attribute to CLOSED and fires a simple event named error at the EventSource object. Once the user agent has failed the connection, it does not attempt to reconnect!" ....this seems to imply that if there is no internet connection currently present, the EventSource connection will fail and not attempt to reconnect. This obviously reduces its usefulness. For example: - A user is connected to the internet via 3G on a train and passes through a tunnel. The connection is lost, so the EventSource object tries to reconnect after x (say 30) seconds. If, when this first reconnection attempt happens, the user has still not regained a network connection, it will fail permanently and never reconnect again. - When a computer wakes from sleep, there is often a delay before the network connection is re-established; this creates a race condition - if the EventSource attempts to reconnect before the network is reestablished it again fails permanently. In my opinion, the failure due to the absence of an internet connection should be a temporary failure, and should ideally schedule a reconnection attempt when the computer next finds a network. The current spec seems to explicitly disallow this, although some browsers are attempting to reconnect anyway. Cheers, Neil.
Received on Sunday, 29 April 2012 18:53:33 UTC