The (formerly undocumented) 'destroy buffer size' configuration option is a very sensible one. This option, applied to the HTTP-based transports prevents clients from sending very large messages and overloading memory on the server. If a client sends a message with a body that exceeds this number, the connection is dropped.
This is necessary because the transports buffer the entire request body before processing. With uncontrolled clients, you have to assume that clients are able to send you any rubbish. This includes infinitely large messages.
Arguably, the default limit (100Mb) is too large, but that's a different problem.
The websockets transport doesn't have any such protection. It happily receives, buffers and then attempts to assemble fragments up to 4Gb each (2^32) indefinitely. I haven't yet tested where this falls over, but I'd be surprised if it didn't.
I'm guessing that the websocket client used in the test harness can't manage later websocket versions. I've concentrated efforts in unit testing on the hybi-16 version, which I am guessing is compatible with RFC 6455, but it doesn't look like integration tests with this version are possible for anything other than default.js so that is the only one that has integration tests.
There is a lot of code duplication in the websocket code, especially between the different hybi versions.
The (formerly undocumented) 'destroy buffer size' configuration option is a very sensible one. This option, applied to the HTTP-based transports prevents clients from sending very large messages and overloading memory on the server. If a client sends a message with a body that exceeds this number, the connection is dropped.
This is necessary because the transports buffer the entire request body before processing. With uncontrolled clients, you have to assume that clients are able to send you any rubbish. This includes infinitely large messages.
Arguably, the default limit (100Mb) is too large, but that's a different problem.
The websockets transport doesn't have any such protection. It happily receives, buffers and then attempts to assemble fragments up to 4Gb each (2^32) indefinitely. I haven't yet tested where this falls over, but I'd be surprised if it didn't.