Aymeric Augustin
Aymeric Augustin
I will have a look this week-end.
> We are not testing CONT frames. They're uncommon in real life and your implementation is simple enough that it's probably right :-) If you want to do a quick...
In the [legacy implementation](https://github.com/python-websockets/websockets/blob/56ee6f81de04a371daa6ad69f0806d146822c4a5/src/websockets/legacy/server.py#L172-L173), when `process_request` returned a response, nothing was logged.
The problem happens because: 1. the Sans-I/O layer [unconditionally sets](https://github.com/python-websockets/websockets/blob/56ee6f81de04a371daa6ad69f0806d146822c4a5/src/websockets/server.py#L538-L543) `protocol.handshake_exc` , when the response status code isn't 101, including when that response is returned normally by `process_request` or `process_response`;...
The current code relies on the fact that these four conditions are either all true or all false: - opening handshake completes successfully - response contains a 101 status code...
I'll try to separate the first two conditions from the last two conditions. Then `process_request/response` can return a non-101 response without an exception.
98f236f8 paved that way.
Oh, how annoying :-( Let's rule out unlikely causes: 1. You aren't sending fragmented messages i.e. calling `send()` with an iterable or async iterable, are you? 2. You kept `close_timeout`...
Thank you for reporting the issue BTW.
Thank you for the information you provided. I'm going to look into it. Probably this will get ironed out long before the deprecation of the legacy implementation completes (5 years)....