I wrote an algorithm to process Websockets data in PHP. Decoding from Chrome/Firefox is fine, but I’m consistently having a problem sending data from the server to the client (Chrome 18, Websockets 13). The server routine automatically responds with “Received” after receiving a message.
There are absolutely no other bytes following the message, as the STDOUT indicates and the WireShark dump indicates (data retrieved via RawCap). In WireShark/RawCap, for some reason, the server->client message appeared under an “ACK” message.
I would REALLY appreciate someone’s insight on this. It’s driving me crazy.
Dustin Oprea
I got it. It turns out that the code that I originally adopted put a single NULL character after the newlines following the handshake-response headers, and I hadn’t noticed this. It looks like a) the browser moves all of the received websocket messages through a character buffer that leaves the single NULL character at the front once the authentication-response is processed, and b) it wasn’t a problem until the -next- message was received.
Flow:
1) Browser (Chrome and Firefox) receives a handshake-response with an extra NULL on the end.
2) Browser approves handshake response.
3) Browser sends a message (in this case, with a “text” opcode, not that it necessarily matters) to the server.
4) Server correctly decodes frames.
5) Server sends a message back through established websocket session.
6) Client complains about having an unexpected continuation frame.
Under some conditions, I believe that I was able to manipulate the message to suppress an error from the browser, but still did not receive the server-message in the browser.
As an example of the above, I believe that, originally, the server was sending an automatic text response of “response”, and got the message above. I later changed this to “1234”, and still got the message above. However, I changed this to “123”, and no longer got the error, but still did not get a message event in the Javascript.
Dustin Oprea