- From: Odin Hørthe Omdal <odinho@opera.com>
- Date: Fri, 27 Apr 2012 13:12:55 +0200
- To: public-webapps@w3.org
- Cc: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>
I think I should do a TLDR since I didn't really get any answers: 1. Should EventSource *ever* time out once it has once been connected? 2. What do browsers do today? What do you think is a good thing to do? I tried Opera, Firefox and Chromium for question 2. Opera: Gives up after 2-3 minutes. Firefox: Gives up after ~15 minutes. Chromium: Doesn't ever give up. Longer and longer retry intervals, upper limit (I think) of 1 minute between each retry. And the TL version follows: On Tue, 17 Apr 2012 16:44:56 +0200, Odin Hørthe Omdal <odinho@opera.com> wrote: > If I understand correcly, the spec expects the implementation to keep > reconnecting indefinitely, when the network cable is yanked. It is a > strong feeling, but it'd be nice to get it clarified in plain text in the > spec. > >> Clients will reconnect if the connection is closed; a client can be >> told to stop reconnecting using the HTTP 204 No Content response code. > >> CLOSED (numeric value 2) >> The connection is not open, and the user agent is not trying to >> reconnect. Either there was a fatal error or the close() method was >> invoked. > >> The task that the networking task source places on the task queue once >> the fetching algorithm for such a resource (with the correct MIME type) >> has completed must cause the user agent to asynchronously reestablish >> the connection. This applies whether the connection is closed >> gracefully or unexpectedly. It doesn't apply for the error conditions >> listed below. > > > And this is the place a small clarification could come in handy: > >> 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. > > Maybe "Network errors after a successfully established connection must > cause the user agent to try reestablishing the connection indefinitely." > > Or something better. At least, make it clear what is going to happen. :-) > > > On that note, it'd also be nice to hear what the other vendors do with > the > connection. It seems like both Firefox and Chromium has an exponential > fallback with a max-value between the reconnection tries. The first tries > will probably respect the given *reconnection time*, but after a while > that'll be too often. > > I tried yanking the network for 10+ minutes, and when I put the cable in > again, both Firefox and Chromium used 25 seconds to reconnect. When only > yanking it for one minute, the reconnection was much faster (2-5 > seconds). > This with *reconnection time* set to 500ms. > -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Received on Friday, 27 April 2012 11:13:33 UTC