Return False in a connect event handler does not close the engine.io connection.

As stated in the document,

After inspecting the request, the connect event handler can return False to reject the connection with the client.

---

Reject the client via returning False

# namespace: /live
class MyNamespace(socketio.AsyncNamespace):
    def on_connect(self, sid, env):
        return False

I found that when returning False in the connect event handler, and a socket.io ERROR packet was received via polling transport before upgrading to websocket.

In the message 44/live, the first 4 means it’s a engine.io MESSAGE packet and the second 4 means it’s a socket.io ERROR packet.

As the result above shows that returning False prevents the socket.io connection to be established, but the underlying engine.io connection is still alive; that is; the websocket is still opened and will still perform those engine.io behaviors such as ping, pong, etc.

---

Reject the client via disconnect()

# namespace: /live
class MyNamespace(socketio.AsyncNamespace):
    async def on_connect(self, sid, env):
        await self.disconnect(sid)

Meanwhile I have another try, I call the disconnect() method instead of returing False.

What I found this time was that before upgrading to websocket, there was a socket.io DISCONNECT packet received via polling.

Also the websocket connection was closed asap.

And finally a engine.io CLOSE packet was received.

---

Question

Is it a feature or a bug that returning False in the connect event handler does not close the underlying engine.io connection but socket.io connection only?

As a result of the current behavior, even if the server rejects the client, the client is still consuming the bandwidth and other resources of the server to perform engine.io behavior.

Why does returning False behave different from disconnect()?

[miguelgrinberg]

Your example will probably fail. You are making the assumption that nothing else will cause a task switch from the time you return from the connect handler until the time the connection is established, and this is actually wrong, because to establish the connection more packets are exchanged, and that creates an opportunity for other tasks to be scheduled to run.

You may want to pass always_connect=True to your AsyncServer class, and then the connect handler is invoked after the connection is established. Returning False in this case issues a disconnect, similar to what you are trying to do.

[miguelgrinberg]

Is it a feature or a bug that returning False in the connect event handler does not close the underlying engine.io connection but socket.io connection only?

This is an area that I consider not well covered in the Socket.IO specification.

You are connecting through the /live namespace, so returning False in the connect event disconnects just that namespace. There could be other namespaces that are still connected, and those would be using the same engine.io connection, so disconnecting everything does not seem to be appropriate here, in my opinion the client should close the engine.io connection once it receives the ERROR packet.

For the disconnect() call, however, you are not passing a namespace, so you are explicitly asking for all namespaces to be disconnected at once, and for that reason the lower level engine.io connection is also disconnected.

I hope that explains the difference in behavior. I don’t think this is a great solution and would be open to revisit this and make this behavior and/or documentation more clear.