On Sun, Jul 2, 2017 at 10:51 AM, Bjorn Reese via Boost
Does Beast re-packet WebSocket frames... ... Yes ... Under what conditions?
There are stream settings for auto-fragmentation of messages into frames of prescribed sizes. Also, when the permessage-deflate algorithm is enabled, Beast reframes messages to fit in the fixed compression and decompression buffers it uses.
The reason I ask is that Beast claims to provide a low-level API, so I would assume that users can have complete control over this.
I don't think that's a good assumption. From https://tools.ietf.org/html/rfc6455#section-1.2 "The WebSocket message does not necessarily correspond to a particular network layer framing, as a fragmented message may be coalesced or split by an intermediary." beast::websocket::stream is considered the first intermediary, and it exercises its privilege to reframe message octets. This is established practice, Autobhan websocket implementations also do this; they have a similar auto-fragment feature (which I copied).
or HTTP chunks?
The "low-level" claims refer to the implementation of the HTTP protocol. It doesn't imply that callers will have control over chunks. Intermediaries along the HTTP path are allowed to rechunk message payloads. Perhaps I have overlooked something. What is the use-case for application level control over chunking?
Does Beast concatenate chunks before passing them to the application layer, or does the application layer get the chunks in the same way as they were received?
The application sees the message body only after the chunked Transfer-Encoding has been removed.
Why does the user not have complete control? Under what conditions will Beast re-packet outgoing chunks?
Beast's implementation does not currently reframe serialized chunks, but there is no specification for how Beast will perform the chunked encoding. This could be changed in the future, if there was a compelling use-case. Thanks