672384 - WebSocket connection drops on moderately-large fragmented messages

Status: RESOLVED FIXED

(Core :: Networking: WebSockets, defect)

Description

[Brian McKelvey]

BACKGROUND:
Used the WebSocket-Node library in node.js to write a test server with matching client to test receiving fragmented messages of various sizes.

The JavaScript client requests increasingly larger messages from the server forever or until the user disconnects.  The purpose is to verify that messages are fragmented correctly by the server and reconstituted correctly by the client.

There is a matching node.js console client that works fine.

Tested against Aurora 7.0a2

Test server can be obtained by cloning the WebSocket-Node git repo:
https://github.com/Worlize/WebSocket-Node

Execute:
test/fragmentation-test-server.js --help
and
test/fragmentation-test-client.js --help

Once the server is running, point Aurora 7 to http://localhost:8080

EXPECTED BEHAVIOR:

Once connected, the browser should continually print out messages indicating that it received increasingly larger messages until the user disconnects or a limitation is reached (i.e. the aggregate message size is too large)

ACTUAL BEHAVIOR:

Firefox will drop the connection and emit an 'error' event from the websocket object on messages that roughly exceed 25,000 bytes.  The threshold of message size that triggers the problem is not entirely consistent, but usually seems to be roughly around 25,000 bytes.  However sometimes it will remain stable for messages up to 100,000 bytes.

Behavior can be compared against the console-mode fragmentation-test-client.js implementation.

The node.js test client and server were run against node v0.4.9

Comment 1

[Brian McKelvey]

Also, when Aurora drops the connection, it does not first send a close frame with the expected error code.  It just instantly closes the underlying TCP socket.

I would expect it to send one of the following error codes to the server before closing the socket:
1002 - Protocol Error
1004 - Message Too Large

Comment 2

[Patrick McManus [:mcmanus]]

Brian, You win a special award of some kind for best test case. If we had such a thing :)

The issue here is a "shift the accumulation buffer" optimization that none of the other fragment test cases have managed to hit. Thanks! It can result in fragmented parts of the message being lost, which resulted in the failure.

Comment 3

[Patrick McManus [:mcmanus]]

Attachment: patch 1

Comment 4

[Patrick McManus [:mcmanus]]

Attachment: patch 1a

forgot to put a comment in the obsoleted patch. code content is the same.

Comment 5

[Brian McKelvey]

A special award?  I'm glad I could be helpful!

Comment 6

[Brian McKelvey]

Oh I should mention that I strongly suspect this bug also affects the current Firefox 6 beta.  I didn't write exhaustive test code for it though because Fx6 implements draft-07 and my code has all been updated for draft-09.  But I did fire up the draft-07 branch of my code to try something against Fx6 and experienced the same problem that originally caused me to look into this issue for Fx7.

Comment 7

[Marco Bonardo [:mak]]

http://hg.mozilla.org/mozilla-central/rev/df6aa347bc83

Comment 10

[Florian Wiechers]

The early bird cathes the worm :)
Thanks!
I'll continue testing on FF8.