W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: [Server-Sent Events] Infinite reconnection clarification

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>
Message-ID: <op.wde73tzb49xobu@odinho-fido.oslo.osa>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:52 GMT