Possible parsing issue about socket.io-erlang HOT 3 CLOSED

That sounds funny.

The implementation should stop handling them when the length is right and return.

I can think of a few reasons:

1. are both messages submitted at once? If so, the parser will read the first header, catch the length, keep that and drop the rest. If it needs to be able to handle many messages that way, it should be easy enough to do, although we'll need to define an API for that.
2. do the messages start by h or j? As far as I know, the heartbeat one should be handled fine, but the json one will then go through the jsx parser, which might just never complain about it and keep looping in the continuation-based API.

It sounds likely it's number 1. Is this some part of the standard socket.io protocol that you should be able to just append messages to each other?

from socket.io-erlang.

After a discussion, we've decided it is likely option no.1 that happens, especially with long polling calls that might buffer them up.

While we would probably need a test case to document everything, I'll just change the parser to return a list of messages if more than one exists.

Seeing the following: https://github.com/yrashk/socket.io-erlang/blob/master/src/socketio_transport_htmlfile.erl#L105

because we use gen_event to handle everything, I should be able to change the bits of code similar to the one above for something that just sends many notices. No messages should be lost after that.

from socket.io-erlang.

This is fixed in 16815ab

Note that it is assumed that the first message of the string is the first one received.

from socket.io-erlang.