On Sun, Jul 9, 2017 at 1:57 PM, Bjorn Reese via Boost
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... 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...
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