Binary response frames are not handled well
pliardb opened this issue · 5 comments
Unless I'm misusing websocat there appears to be two issues with how it handles binary response frames:
- An extra trailing \n is added to the payload
- \n characters within the payload are replaced with space characters. The payload should be returned as-is, without any byte conversion
Perhaps I missed a particular command-line flag to use? Thank you.
-b
?
Thanks a lot for the very quick reply. I'll give this a try and report back. I may have seen and discarded this option earlier when seeing in the description message that it applied to the request (in my case the request is in text and the response in binary). I should have given it a chance though.
--dump-spec
option shows debugging output, depicting auto-inserted message-to-line and line-to-message convertors in text mode (which is the default).
Those conversions allow scripts to rely on one message = one line. --no-line
and --no-fixups
turn off those auto things.
Thanks a lot, --no-fixups
did the trick. Perhaps websocat could default to this when dealing with a binary response frame. Though I think this particular issue could probably be closed given the existence of --no-fixups
.
By default Websocat assumes text messages to be sent and received and is aimed primarily at interactive testing of WebSocket endpoints (e.g. using something rlwrap websocat ws://127.0.0.1:8080
).
-b
switches it to binary mode, aimed primarily at websocat -b ... < upload_file > download_file
or interconnection with a plain TCP.
There are other, trickier modes for mixing text and binary messages flexibly.
--no-fixups
also turns off lints (warning messages when Websocat detects potentially problematic command line) and can lead to errors when advanced features are used, so it seems to be a poor default.