The default bug view has changed. See this FAQ.

WebSocket connection drops on moderately-large fragmented messages

RESOLVED FIXED in mozilla8



Networking: WebSockets
6 years ago
5 years ago


(Reporter: Brian McKelvey, Unassigned)


7 Branch
Mac OS X

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [inbound])


(1 attachment, 1 obsolete attachment)



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

test/fragmentation-test-server.js --help
test/fragmentation-test-client.js --help

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


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)


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

6 years ago
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
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.
Ever confirmed: true
Created attachment 546774 [details] [diff] [review]
patch 1
Attachment #546774 - Flags: review?(cbiesinger)
Created attachment 546776 [details] [diff] [review]
patch 1a

forgot to put a comment in the obsoleted patch. code content is the same.
Attachment #546774 - Attachment is obsolete: true
Attachment #546776 - Flags: review?(cbiesinger)
Attachment #546774 - Flags: review?(cbiesinger)

Comment 5

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

Comment 6

6 years ago
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.
Attachment #546776 - Flags: review?(cbiesinger) → review+
Whiteboard: [inbound]
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla8
Duplicate of this bug: 690703
Duplicate of this bug: 691733

Comment 10

6 years ago
The early bird cathes the worm :)
I'll continue testing on FF8.
You need to log in before you can comment on or make changes to this bug.