The outcome of the formal review of Boost.Http is that the library is NOT accepted for inclusion into Boost this time. Below I will first summarize the main themes running through the review, and afterwards I will make some recommendations about how to proceed from here. The following reviews were posted: - Antony Polukhin: No - Darren Cook: No - David Sankel: No - Lee Clagett: No - Niall Douglas: Yes, conditionally - Roland Bock: No - Tom Kent: No The discussions were constructive and offered much valuable feedback. There was a general consensus that Boost ought have a HTTP library, but that Boost.Http was too incomplete in its present state. Many reviewers mentioned the disconnect between their expectations and what the library offered. There were several suggestions for alternative names for the library to better reflect the feature-set it offers. Boost.Http currently only provides a server-side API, but the reviewers felt that a client-side API would be usable to more users. There was also a recurring request for Boost.Http to be a header-only library. The HTTP parser currently used is not header-only and that is the main obstacle towards a header-only Boost.Http library. Some of the discussion revolved around what level of abstraction would be appropriate for Boost.Http. The views ranged from wanting higher- level APIs all the way down to simply wanting a HTTP parser/generator and then leave all the socket and buffer management up to the user. Regarding the HTTP parser/generator, there is no reason why it cannot be a separate Boost library. However, Vinicius correctly pointed out that this is insufficient for a HTTP server framework that handles multipleback-ends (e.g. HTTP/2, FastCGI, or WebSocket). By implication it cannot handle HTTP upgrade requests either. Some reviewers also felt that HTTP/2 should be part of Boost.Http, partly because that would demonstrate the extensibility of the current design, and partly because the library would be in a stronger position to attract users if it offers more than its competitors. There was concern about whether or not the Boost.Http API can be extended to HTTP/2. The main challenge with HTTP/2 is fitting multiplexing into the API. Vinicius suggested that there should be a http::socket per multiplexed channel, so it will be transparent to the user if several of his http::sockets to the same remote endpoint are transported via the same TCP socket. This will keep the API clean when extended to HTTP/2. Boost.Http currently creates an associative array for all header fields. One reviewer explored the idea of using an incremental (push or pull) HTTP parser as part of the API to let users decide which header fields to copy and which to discard. There was a general consensus that more examples are needed, and that the tutorial should have smaller examples. The Boost.Http code base currently builds with CMake. This must be converted into Boost.Build before being integrated into the Boost code base. Several other third-party tools were suggested, but as these are not requirements for inclusion into Boost I will leave the decision to the author. As for the future, I hope that Vinicius is not too discourage by the current rejection, and that he will consider re-submitting the library at a later stage. Judging from the reviews, the following additions will make a future submission more likely to succeed: 1. Involve the community more during the development. This will both solicit earlier feedback on the design, and help to align community expectation. 2. Provide a client-side API. 3. Design higher-level APIs on top of the low-level APIs. 4. Better documentation and more examples. I also hope that people in the community will consider contributing to the library. For example, a good opportunity is to help creating the higher-level APIs. Another opportunity is to help with the (header- only, possibly incremental) HTTP parser/generator, which could be a separate library.