using websockets (ietf-07) in conjunction with pywebsockets (07) and deflate-stream can result in non-clean connection closes once in a while when the client is the first to close. This doesn't happen with deflate-stream disabled.
this can be seen occasionally as an intermittent fail on test_websocket.html or test_ws_basic_tests if deflate stream is enabled.
According to some logging:
* the client js closes the websocket
* the client sends the ws close frame to the server (but no tcp close)
* the server sends a tcp close (eof)
+ one possibility is that the server needs a fix (it is somehow swallowing the ws close it should be sending before the tcp close)..
+ another possibility is that our close is somehow malformed and the tcp close we get from the server is how it reacts to a protocol exception.
+ another possibility is that the end of our compression stream is being interpreted as a tcp close by the server and it is aborting as if we had hung up.
deflate-stream is just an extension and is preffable, so the right thing to do for the immediate term is to just pref it off while I figure out what is going on so the rest of the code can get some experience.
Created attachment 533986 [details] [diff] [review]
disable deflate-stream pref v1
in the end this is a server issue in pywebsockets. the server isn't draining the final framing bytes of the compression before it does a socket close, which results in a RST being generated. This RST can pre-empt the WS close it had already sent in a race condition.
I'll file a different bug about patching the server and re-enabling the extension.