Subject: Re: [boost] [beast] Chunking example
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2017-07-02 18:04:57
On Sun, Jul 2, 2017 at 10:51 AM, Bjorn Reese via Boost
>>> Does Beast re-packet WebSocket frames...
> 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
"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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk