Improper Interpretation of payload length about websocketlistener HOT 8 CLOSED

Interesting. The problem is that unsigned integers are not CLS compliant. Can you explain the issue with negative payload lengths?

from websocketlistener.

https://tools.ietf.org/html/rfc6455 - Page 29.

In condition 2, where payload data is 126, if next 2 bytes are interpreted as an int, then if your payload is greater than 32767 in length (0x7FFF), then your contentLength will be rolled over into negative territory, breaking the rest of the implementation.

In condition 3, where payload data is 127, if next 8 bytes are interpreted as an int, then if your payload is greater than 9.223372e+18 in length (0x7FFFFFFFFFFFFFFF), then your contentLength will be rolled over into negative territory, breaking the rest of the implementation.

Clearly, no sane person would expect to be bothered by condition 3, but for condition 2, any message of size 32768 (0x7FFF) to I believe 65535 (0xFFFF) would result in an unfavourable situation.

from websocketlistener.

Great. I won't have a laptop handy until Monday. I will try to reproduce these situations in th unit tests about header parsing. Thanks.

from websocketlistener.

Also, as I understand, for CLS compliance, only public members must be signed, whereas private members, internal members, and temporary variables used in the implementation/logic, can be unsigned.

from websocketlistener.

That is right. I have done the pertinent changes in the changeset : f0a2cc2

Let me know your thoughts. And thanks for taking the time in reporting this.

from websocketlistener.

Great, so receiving in all cases of the above case 2 works well (from sizes 32768 (0x7FFF) to 65535 (0xFFFF) in content length) however, you need to make the same changes when you build and send your frame headers. As is stands, message being sent that are between 32768 (0x7FFF) and 65535 (0xFFFF) in content length will once again cause a critical error in generating an incorrect frame header.

I believe this is because of your use of Int16.MaxValue rather than UInt16.MaxValue in several areas, and your ByteArrayExtenstions also do not implement the unsigned counterparts. As for very large messages (Int64.MaxValue < x < UInt64.MaxValue) your library will simply throw an exception and refuse to send it, for the same reasons.

from websocketlistener.

Right, I just came from holidays so bear with me :)

I fixed the header creation as well: 8c9361d

(some changes to fix the CLS compliant thing have been added later)

There is no need to throw an exception since the creation helper only allows Int64.

from websocketlistener.

This is fixed in the latest version : https://www.nuget.org/packages/vtortola.WebSocketListener/2.1.9

Cheers.

from websocketlistener.