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
6 years ago
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.