When using the WebSocket-Sharp library in C# to build a WebSocket client, I am finding that sending messages doesn't work properly.
If I send the server a particularly long string as text frame, the WebSocket-Sharp library truncates it to 1,016 characters, which it sends as text, but then continues the rest of the data in a continuation frame and converts it into binary instead of text.
Is there any way to disable this behavior? It makes the library unusable in my case since the server doesn't respond after the continuation frame.
Here is an example taken from a Fiddler log:
22:06:33:8486 WSSession5.WebSocket'WebSocket #5'
MessageID: Client.28
MessageType: Text
PayloadString: *//Original data redacted//*
Masking: 60-96-90-D9
22:06:33:8642 WSSession5.WebSocket'WebSocket #5'
MessageID: Client.29
MessageType: Continuation
PayloadString: 5F-6F-61-75-74-68-5F-74-6F-6B-65-6E-22-3A-22-22-2C-22-6C-6F-63-61-74-69-6F-6E-5F-61-67-65-22-3A-22-22-2C-22-6C-6F-63-61-74-69-6F-6E-5F-6E-61-6D-65-22-3A-22-55-53-22-2C-22-6D-69-64-73-69-7A-65-5F-61-76-61-74-61-72-22-3A-22-22-2C-22-6D-69-6E-75-73-5F-73-63-6F-72-65-22-3A-22-22-2C-22-74-75-6D-62-6C-72-5F-62-6C-6F-67-5F-75-72-6C-22-3A-22-22-2C-22-6F-63-63-75-70-61-74-69-6F-6E-22-3A-22-22-2C-22-72-65-6C-61-74-69-6F-6E-73-68-69-70-5F-73-74-61-74-75-73-22-3A-22-22-2C-22-74-75-6D-62-6C-72-5F-62-6C-6F-67-5F-6E-61-6D-65-22-3A-22-22-2C-22-73-68-61-72-65-5F-75-72-6C-22-3A-22-22-2C-22-73-6C-75-67-22-3A-22-63-68-69-67-6F-74-79-22-2C-22-73-6E-69-70-70-65-74-22-3A-22-22-2C-22-73-6E-69-70-70-65-74-5F-65-78-70-6C-6F-72-65-5F-73-65-61-72-63-68-5F-68-74-6D-6C-22-3A-22-22-2C-22-73-6E-69-70-70-65-74-5F-65-78-70-6C-6F-72-65-5F-76-32-22-3A-22-22-2C-22-73-6E-69-70-70-65-74-5F-66-61-76-65-73-22-3A-22-22-2C-22-73-6E-69-70-70-65-74-5F-66-61-76-65-73-5F-73-65-61-72-63-68-5F-68-74-6D-6C-22-3A-22-22-2C-22-73-6E-69-70-70-65-74-5F-68-74-6D-6C-22-3A-22-22-2C-22-73-6E-69-70-70-65-74-5F-70-69-63-6B-65-72-22-3A-22-22-2C-22-73-6E-69-70-70-65-74-5F-70-69-63-6B-65-72-5F-68-74-6D-6C-22-3A-22-22-2C-22-73-74-61-74-75-73-22-3A-22-22-2C-22-73-68-61-72-65-64-22-3A-2D-31-2C-22-73-63-6F-72-65-22-3A-2D-31-2C-22-6D-75-74-75-61-6C-5F-66-72-69-65-6E-64-5F-63-6F-75-6E-74-22-3A-2D-31-2C-22-6C-69-6B-65-73-22-3A-2D-31-2C-22-6B-61-72-6D-61-22-3A-2D-31-2C-22-69-74-65-6D-73-5F-73-68-61-72-65-64-22-3A-2D-31-2C-22-66-6F-6C-6C-6F-77-69-6E-67-5F-63-6F-75-6E-74-22-3A-2D-31-2C-22-66-6F-6C-6C-6F-77-65-72-5F-63-6F-75-6E-74-22-3A-2D-31-2C-22-61-67-65-22-3A-2D-31-7D-2C-22-73-74-61-74-75-73-22-3A-22-53-45-4E-54-22-2C-22-63-61-63-68-65-49-64-22-3A-30-2C-22-69-6E-63-6F-6D-69-6E-67-22-3A-66-61-6C-73-65-2C-22-72-65-61-64-22-3A-66-61-6C-73-65-7D-2C-22-69-6E-73-65-72-74-5F-69-66-5F-6D-69-73-73-69-6E-67-22-3A-74-72-75-65-2C-22-61-6C-6C-6F-77-5F-63-61-6D-65-72-61-22-3A-66-61-6C-73-65-2C-22-73-69-6C-65-6E-74-22-3A-66-61-6C-73-65-2C-22-74-79-70-65-22-3A-22-4F-4E-5F-53-45-4E-44-5F-4D-53-47-22-7D
Masking: 60-96-90-D9
I was able to change this behavior by modifying the FragmentLength variable in the WebSocket class.
Just downloaded the open source project from GitHub, found that the default length before fragmentation is 1016, and max length is Int32.MaxValue - 14. I recompiled the DLL after changing FragmentLength to 1016*20 and referenced the modified DLL. Problem solved.