658546 - websockets - deflate stream and pywebsockets-07 unclean closes

Status: RESOLVED FIXED

(Core :: Networking: WebSockets, defect)

Description

[Patrick McManus [:mcmanus]]

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.

Comment 1

[Patrick McManus [:mcmanus]]

Attachment: disable deflate-stream pref v1

Comment 2

[Patrick McManus [:mcmanus]]

http://hg.mozilla.org/mozilla-central/rev/9c8537aa965a

Comment 3

[Patrick McManus [:mcmanus]]

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.