Aymeric Augustin
Aymeric Augustin
Based on code inspection, in the old asyncio implementation, you should get an HTTP 500 error and a message at the ERROR log level in that case. In the new...
Thank you for reporting this bug! The legacy implementation includes [this logic](https://github.com/python-websockets/websockets/blob/5209b2a1cba00b28b8f62502157d5dbb98625a49/src/websockets/legacy/protocol.py#L1127-L1134), suggesting that this is the right fix in the Sans-I/O layer. I'd like to double check and add...
Thank you for the details - that's very useful!
The commit message for b2a95c45fae19fff0a3473158dd02afe2ca42604 suggests that the current behavior of the Sans-I/O layer is intentional. Mmm.
For clarity, the problem happens in the following scenario: * `Protocol.send_close()` sends a Close frame and changes the connection state is CLOSING * `Protocol.receive_data()` receives data containing a Ping frame...
Above I described the scenario where the connection state is CLOSING because we initiated the closing handshake. The connection could also be closing because the other side initiated the closing...
RFC 6455 says: > Upon receipt of a Ping frame, an endpoint MUST send a Pong frame in response, unless it already received a Close frame. Note that it doesn't...
Superseded by #1435.
In an earlier comment, you said: > I can replicate this reliably in the REPL If you could double-check that #1435 fixes the problem for you, that would be most...
To make sure we're clear on the setup: - you want to run the server in another thread (so it runs in the background while the test code runs in...