A story of a potiential issue not being an issue at all.

Jan 30, 2012 at 9:20 AM


When reading through the sources I thoght there might have been a rare condition the WebSocketHeaderReader did not yet account for.

It currently searches incoming data segments for a byte sequence representing "\r\n\r\n".

If the trailing bytes of a data segment are a prefix of the pattern, it will start searching the next segment using only the portion of the pattern that has not yet been detected.

If this doesn't lead to a match, it will search the rest of the new data segment using the full pattern again.

When a match is found, it will build a string from the bytes in the previously processed data segments, and from the current one as well, if required.

The pattern usually is not part of the result.

In the case, where terminating sequence is spread over multiple data segments, the result would contain the leading part of the pattern though, because WebSocketHeaderReader would not take into consideration the number of bytes already matched at the end of the second-to-last data segment.

Which I thought to be potentially wrong.

The good thing is, though, that for the pattern used and the way the data is being processed later on, it does not make a difference at all:

Any possible prefix of the pattern included in result would lead to StringReader.ReadLine returning an empty string inside WebSocketServer.ParseHandshake, a condition which is interpreted there as the end of the Header. :-)

Feb 7, 2012 at 10:08 AM

This issue has been fixed in the release of 0.3!