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.) Darren