Add support for continuation frame in WebSocketMessageParser

[dm385]

This PR fixes #1647 by adding support for parsing continuation frames.

[an-tao]

@dm385 Thanks so much for your patch, I changed some code to use loops instead of recursion. Please check if it is correct.

[dm385]

Seems like it's coming to an infinite loop in my case now, but haven't had the time to look at it more closely.

[Copilot]

Pull Request Overview

This PR adds support for parsing continuation frames within the WebSocketMessageParser, addressing issue #1647.

• Introduces looping to process frames as long as sufficient data is available.
• Adds boundary checks and overflow protection when reading extended payload lengths.
• Adjusts buffer retrieval logic for both masked and unmasked frames based on FIN flags.

[Copilot]

Consider adding a comment to clarify that the while loop is intentionally used to process multiple frames in a single parse call, ensuring that continuation frames are handled correctly.

[Copilot]

Add a comment clarifying that this check prevents an overflow when accumulating the extended payload length, ensuring safe processing of large payloads.

[Copilot]

[nitpick] Review whether consuming the entire frame, regardless of the FIN flag, is the intended design for continuation frames. A brief inline comment explaining this decision may improve clarity for future maintainers.

Suggested change

	}
	}
	// Consume the entire frame from the buffer, regardless of the FIN flag.
	// This is necessary to process subsequent frames correctly, as the WebSocket
	// protocol allows fragmented messages. The `message_` buffer accumulates
	// data from all frames, and the `isFin` flag determines when the message
	// is complete.

[hwc0919]

Just make sure that illegal data won't end up in an infinite loop.

[marty1885]

This does not feel right. size_t is different on 32 and 64bit systems. So the max size will be 24 and 48bits respectively. Do you intend to use uint64_t?

[an-tao]

The judgment is followed by an 8-bit left shift operation, so the maximum values ​​are 32-bit and 64-bit respectively. I think this judgment protects the 32-bit system from overflow.

[marty1885]

On 32bit system this is 16M. Which is not big in modern standards. Is this really ok? And on 64bits 2^56 is, a lot. I think we should have a consistent limit instead of "it depends on the processor"

[dm385]

The infinite loop does not occur anymore for my case. Thank you!

[dm385]

Just make sure that illegal data won't end up in an infinite loop.

@hwc0919 why do you think it is "illegal" data?