1512438 - network.websocket.delay-failed-reconnects is patronising developers

Status: RESOLVED INVALID

(Core :: Networking: WebSockets, defect)

Description

[gnopap]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36

Steps to reproduce:

* create a websocket connection
* implement reconnect functionallity
* disconnect/shut down your websocket server


Actual results:

Observe how firefox puts arbitrary delays between reconnect attempts.


Expected results:

No arbitrary reconnect delays between reconnect attempts.

Comment 1

[gnopap]

If you really insist we need something like this, I recommend using a **fixed throttle** instead of ever increasing delays after each failed attempt.

Comment 2

[Valentin Gosu [:valentin]]

Thanks for the bug report, but according to bug 711793 comment 0, and the RFC, we are doing exactly what the RFC specifies.
I'm going to close this for now.
If you disagree, please reopen and state your case _why_ you think we should remove the increasing delays.

Comment 3

[gnopap]

Yes, you did. However that specification says *SHOULD*. Also, please consider that (optional) specifications do not necessarily imply it is a sensible thing to do. I do not know of any browser that puts in ever increasing delays after new connections, simply because it makes application development unpredictable.

Comment 4

[gnopap]

Further, what this clause is trying to do is protecting the developer from himself. If we were to do that consistently, we should simply remove Javascript and similar techs all together.

Comment 5

[Valentin Gosu [:valentin]]

(In reply to gnopap from comment #4)
> Further, what this clause is trying to do is protecting the developer from
> himself. If we were to do that consistently, we should simply remove
> Javascript and similar techs all together.

Actually, there are lots of reasons why a reconnect might fail. If all the clients would try to reconnect at the same time, and would do so without a delay, it could spam their own network (depending on the number of websockets) or the server with new connections. The delay is common sense. For development purposes, you can always flip the pref and have a predictable reconnect pattern.

Comment 6

[gnopap]

I think you miss the point here. Yes, there are lots of scenarios where a reconnect would fail. All of them can be handled by the average developer by hooking appropriate callbacks and using debounce/timeouts mechanisms. The browser itself is just not the right place to do this kind of abstraction - that should be up to the lib, framework or app that is making use of the WebSocket API.

Again, if I cannot persuade you to drop this sort of protection completely, I'd like you to consider a fixed throttle instead; which is what chromium seems to be doing. This would be much more sensible and can be worked with when implementing a reconnect mechanism.

However, in any case, I'll drop the issue now as I doubt it's worth further elaboration.