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
