large binary messages (>131072) from Chrome JavaScript fail/ignored

[blainebell]

Calling WebSocket.send() with an ArrayBuffer greater than 131072 bytes gets ignored by the Java-WebSocket JAVA server. It looks like there is a problem reading the length of the message in org.java_websocket.drafts.Draft_10.translateSingleFrame(), but I am not sure about whether the server is detecting the correct format. Does anyone have an idea?

These calls work just fine on FireFox and Safari, have not tested IE/Edge yet.

My version of Chrome is Version 47.0.2526.111 (64-bit)

Thanks in advance!

Blaine

[blainebell]

I was able to "work around" this on Chrome by chunking the messages into separate send() calls, and combining them on the server. However, I needed to set 50ms timeouts between send() calls to get the server to receive the messages (i.e., calling setTimeout() for each send). Not sure if this is a problem on the client or server side (I would assume server). In any case, if anyone knows about the above problem, whether its just a different format/protocol that Chrome uses, I would be grateful. Thanks! Blaine

[jnblanchet]

I'm having the same problem. Message fragmenting is suppose to be handled internally by Java-WebSocket. Does anyone have a solution to this?

[kemorrisnf]

Got bitten by this too. At the very least an exception should be thrown indicating that too much data was sent.

[ritzyramen]

Wondering if there's been any progress on this. Looks to me like it's probably chrome and not this server websocket implementation. I'm manually implementing websockets in Node, parsing the frames manually, and at 131071 the correct bytes are received, ie [1, 255, 255], and on 131072 or greater, it only reads [2, 0, 0]. And this does hold for much greater values. Oddly I'm still receiving the data, it looks like chrome just isn't constructing the opening frame correctly. This doesn't seem to be the only issue with chrome's websocket frame construction, as each frame for a message should still have the header bytes. For more context, after about 32kb it splits a message into multiple frames, but sends the rest of the message without mask information, so I need to preserve the mask externally.

This may be correct but the implementation says there should be a FIN bit, implying that when chunking occurs there should still be header bytes. I'm going to work around this for now by calculating the length minus 4 and storing it in the first 4 bytes of each message. This is severely less than ideal, requiring client side hoops but the performance server side is worth it. Hoping I'm just missing something obvious.

[ainslec]

Having same issue.

[marci4]

duplicate of #423