Support Message Fragmentation

[EnTerr]

I thought of spinning my observation from here #94 (comment) into separate issue, here it goes:

It seems that receive (not only in sync but otherwise too, see https://github.com/lipp/lua-websockets/search?utf8=%E2%9C%93&q=first_opcode ) concatenates bunch of frames into a single string and returns the 1st opcode only! Meaning that if the 1st opcode was PONG, everything will get labeled so, regardless it is BINARY/TEXT. Or if the 1st opcode is BINARY and PONG is one of the next frames, it will disappear.

When i think of it - a mix of BINARY / TEXT / etc all gets "mushed" together and that should not be the case. Because e.g. TEXT is UTF8 and should be handled differently.

Seems to me a proper handling should return only 1 frame and its corresponding 1 opcode, keeping the rest for the next call - perhaps akin to how i "save" frames for later consumption in #80

[lipp]

Thanks! This is awful... but true.

http://stackoverflow.com/questions/37561273/are-intermixed-websocket-frame-types-spec-conforming-are-there-implementations?noredirect=1#comment62611439_37561273

https://tools.ietf.org/html/rfc6455#section-5.4

[EnTerr]

Oh, so the situation is better than i thought?
So frames in the source actually means "fragments" of one-and-the-very-same frame, not different/separate "frames" as i assumed.

Baring "negotiated extensions", the only other frames that can be interspersed are the (non-fragmentable) control frames then? In the case of PING, that can be handled with an immediate PONG (with copy of the payload) and losing the ping frame. In the case of PONG, perhaps that can be returned first, with the remaining fragments saved for the frame to be completed next call?