Subject: Re: [boost] [http] Formal review of Boost.Http
From: Darren Cook (darren_at_[hidden])
Date: 2015-08-08 13:19:00
> What I should have said was this: Standalone ASIO is the reference
> Networking TS implementation for standardisation. Http is currently a
> set of extensions to Boost.ASIO specifically when it *should* be a
> set of extensions to the reference Networking TS implementation for
> C++ standardisation. This is why your current design and architecture
> is flawed, but luckily there isn't too much work to fix this by
> finishing the port of Http to the Networking TS.
(Q. for Niall Douglas)
Does this change the public-facing API of the proposed Boost.http, or
just the implementation?
>>> * I don't understand why you cannot issue more than one async read at
>>> a time nor async write at a time. In something like pipelined HTTP
>>> that seems like a very common pattern. ...
>> Too much synchronization and buffering.
>> The pipeline has the following requests:
>> A => B => C
>> If I were to allow replies to request B, the design would be more complex,...
(Q. for VinÃcius)
Using the diagram at http://stackoverflow.com/q/10480122/841830, does
the above mean that Boost.Http only supports the left-most diagram (e.g.
a browser client cannot request image.png until it has received the
entirety of index.html)?
I'd share Niall's concern that moving to HTTP/2 might require API
changes. In addition to the arrows shown on the rightmost diagram in the
above link, HTTP/2 also supports sending back a file that has not been
requested yet. And it supports one of those arrows being a WebSocket or
SSE connection that continues to send data.
It'd be good to see a code example of how an HTTP/2 server would work,
with all these features present. (I.e. even if it won't compile yet.)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk