Corrupted frame content + workaround about ocaml-websocket HOT 4 OPEN

In that case, perhaps there should be two interfaces, one that uses bytes and is free to trash the buffer when it's done, and one that uses string, so that this unexpected behavior is clearer?

from ocaml-websocket.

Ha I think this is because I mask the frame in-place before sending it to the client, as the websocket protocol requires. The right thing to do is indeed probably to make a copy of the content and not mask-in-place to avoid the issue you encountered. So option 2 :)

from ocaml-websocket.

I think for performance reasons the current behaviour should be kept or be enabled with a parameter. That's also how high-performance WebSocket libraries like uws do it.

from ocaml-websocket.

Since I upgraded to 2.7 today, I have a (maybe) related problem when accessing the content of received frames. I have no simple repro case but here is what I do:

  let handler conn_client =
        let req = Websocket_lwt.Connected_client.http_request conn_client in
        let recv () = Websocket_lwt.Connected_client.recv conn_client in
        let send = Websocket_lwt.Connected_client.send conn_client in
        let stream = Websocket_lwt.mk_frame_stream recv in
        <handle stream of frames>
  in
  let (waiter, stopper) = Lwt.wait () in
      let thread = Websocket_lwt.establish_standard_server
        ~stop: waiter ~ctx ~mode:server handler
      in
      Lwt.return { stopper ; thread }

When handling the stream of frames, I ignore the frames with opcode <> Websocket_lwt.Frame.Opcode.Text but the content of Text frames seems to be binary data.

from ocaml-websocket.