This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
As per the spec https://html.spec.whatwg.org/multipage/comms.html#processing-model-10 , when EventSource fail to establish the connection first time, it should retry to connect to given URL after time specified in the "retry" field/UA default value. But Spec doesn't tell specifically what should be done if retry attempt fails. And since this "retry" field is in seconds, Browser should try only once or is it retry interval(i.e browser should keep on retrying after every retry seconds). For eg: var evtSource = new EventSource("http://www.test.not") evtSource.onerror = function() { console.log(evtSource.readyState); } In above case Browsers behavior is : Firefox retries only once and if it fails to establish the connection to given URL it closes the connection. But Blinks keep on retrying for given URL with readyState set to CONNECTING. Can spec be more specific on this i.e what should be done if it fails to connect even after retry?
"Optionally, wait some more. In particular, if the previous attempt failed, then user agents might introduce an exponential backoff delay to avoid overloading a potentially already overloaded server. Alternatively, if the operating system has reported that there is no network connectivity, user agents might wait for the operating system to announce that the network connection has returned before retrying." is pretty clear, no?
(In reply to Anne from comment #1) > "Optionally, wait some more. In particular, if the previous attempt failed, > then user agents might introduce an exponential backoff delay to avoid > overloading a potentially already overloaded server. Alternatively, if the > operating system has reported that there is no network connectivity, user > agents might wait for the operating system to announce that the network > connection has returned before retrying." is pretty clear, no? Hi Anne, thanks for the reply. Please correct my understanding - In the example what I have mentioned it is particularly about DNS resolution failure. As per the spec "Network errors that prevents the connection from being established in the first place (e.g. DNS errors), must cause the user agent to reestablish the connection in parallel." And Now we will try to reestablish the connection and spec says "Alternatively, if the operating system has reported that there is no network connectivity, user agents might wait for the operating system to announce that the network connection has returned before retrying." But this is a case of "Name Resolution failure", not about N/W connectivity problem as given URL(http://www.test.not) itself is invalid even though N/W connection exists. So my bug report was particular about this kind of scenarios, where N/W connectivity exists but reason for retry may be other N/W related errors, how to handle this?
That set of steps is invoked from "Network errors that prevents the connection from being established in the first place (e.g. DNS errors), must cause the user agent to reestablish the connection in parallel." though. But yeah, the specification should probably be updated to allow disconnecting somewhere there as well in clear cut scenarios.
https://github.com/whatwg/html/pull/226