Boost logo

Boost :

Subject: Re: [boost] [beast] Formal review
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2017-07-12 11:47:21


On Sun, Jul 9, 2017 at 1:57 PM, Bjorn Reese via Boost
<boost_at_[hidden]> wrote:
> Building an API around this model should offer read/write functions that
> handles partial bodies (whether chunked or progressively downloaded.)
> The current collect-entire-message API could be build on top of that.
> With this approach there is no need to mess around with custom parsers.

Beast already works this way. See:

<http://vinniefalco.github.io/stage/beast/review/beast/ref/beast__http__async_read_some.html>

Callers can also provide their own fixed size buffers and read the
message body progressively, chunked or otherwise, as shown below. This
feature was in the review branch but the documentation page is new:

<http://vinniefalco.github.io/beast/beast/using_http/parser_stream_operations/incremental_read.html>

> On another topic, the HTTP status codes can be roughly categorized as
> instructions (the 1xx and 2xx series) and errors (the 4xx and 5xx
> series.) I recommend that you create two error categories and pass
> status codes as error_code.

Consider:

    read(stream, buffer, res, ec);

After reading a complete response message, does `ec` evaluate to
`true` or `false`? How does one distinguish between, say ECONNABORTED
and "403 Unauthorized"? Requests do not have a status so any errors
generated receiving them would be "real" errors. Responses would be
treated differently under your scheme. Every call site would have to
check "is this a real error". I don't think this is a good idea.

> The Reference is missing some concepts, e.g. SyncReadStream.

Did you see this page?

<http://vinniefalco.github.io/stage/beast/review/beast/concept/streams.html>

SyncReadStream is a Boost.Asio concept.

Thanks


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk