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