beast: Buffer with uint8_t type invalid encoding
Version of Beast
Latest develop
Steps necessary to reproduce the problem
void sendResponse(websocket::stream<tcp::socket>& ws)
{
std::array<uint8_t, 1> err_buff{{ static_cast<uint8_t>(140) }};
ws.binary();
ws.write(std::array<boost::asio::const_buffer, 1>{{
{ err_buff.data(), err_buff.size() }
}});
}
clang 4.0.1
Calling it via the browser like this:
const socket = new WebSocket('ws://localhost:3003');
socket.addEventListener('message', (event) => {
console.log("Server sent: ", event.data);
});
socket.addEventListener('open', (event) => { socket.send("hello"); });
Results in: failed: Could not decode a text frame as UTF-8
Changing the number from 140 to something below 128 avoids this error.
Which makes me think it has something to do with interpreting the buffer in a certain way.
It’b be great to have a fast response, as this is somewhat of a roadblock.
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 15 (8 by maintainers)
140 is not a valid character for the first byte of a UTF-8 code point. If you want to send binary data, set the message type to binary before sending the message data, like this:
I’ll try my best to convey that beast is not a high level abstraction, much rather a toolkit to implement such, and by that, tries to achieve a different goal and should be compared accordingly.
A code review would be great. The 2 best ways I found to create a review of a single file. Is to either create a pull from the earliest non related commit like this. Note there is a lot of clutter this way, as every other change is also included. Or you could comment on the individual commits found via the blame overview.
Ok, so
std::bindis not as bad as I had in memory. Given C++11 as requirement there is some reason for using it. However lambdas are cleaner as they are a direct compiler construct and are aloud to have no size. Also if called improperly can lead to loss of performance.