Hello, This is my formal review of Boost Beast.

What is your evaluation of the design?

Also the general design is solid provides generic API that does the job it defined. The most problematic issue with Beast is it total reliance on static polymorphism. This comes to sometimes very painful issues like: Having the object code duplicated for different variants HTTP/HTTPS code Having all the implementation in headers increasing compilation time Adding complexity to end user since he needs to propagate the templates to various places. Virtually all concepts could be done with classic interfaces and virtual functions. Using of static polymorphism does not provide there performance advantage but reduces code maintainability and adds lots of headache to end user. Note: it does not contradict of using ASIO but lots of stuff could be pimpled or hidden having only few forward declarations of the relevant classes.

What is your evaluation of the implementation?

From what I seen didn't find may flows besides thous mentioned before (content-length - that was fixed) and non-blocking sockets aren't covered by tests.

However I didn't look too much since the code is quite hard to read being too template heavy. Second major issue is that it puts all the heavy work on end user providing tiny parsing messaging layer that to be honest is the simple part of HTTP handing. It significantly limits its usability to virtually void.

What is your evaluation of the documentation?

Documentation is OK - similar to ASIO - I think more examples should be needed and tutorials regarding how to do common tasks.

What is your evaluation of the potential usefulness of the library?

VERY limited. The library does too little to be useful for real development. I don't really see a real need for a library that could potentially be used to create CURL or could potentially be used to write web framework that users will work over them. As a user of this library you need to deal with: - User has to have deep knowledge of HTTP protocol itself and be highly aware of various security related problems on WWW. - Protocol itself and know it up to the small details, timeouts and much more. - Being able to parse all parameters passed from getting query string, parsing multipart/form-data (a.k.a. file upload format) parse percent encoding, cookies. I suggest to drawing the line at some point when library becomes useful for somebody who for examples needs to implement RESTful service or send some post data to a form. The separation line that was drawn does not suite the needs of too many of potential users. I understand it is huge task to do but if first lines in your FAQ and many other talk about what the library doesn't do than probably something goes wrong. And please note I don't talk about sessions, url mapping, but much more basic stuff like multipart parsing, url-encoding. URL parsing,

Did you try to use the library? With which compiler(s)? Did you have any problems?

Tried to compile several examples no problem.

How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?

At least 10-12 hours of reading documentation, code, running some examples. Notifying potential problems.

Are you knowledgeable about the problem domain?

Yes, I'm myself an author of CppCMS C++ Web Framework - fully featured web development platform for C++ that works in both synchronous and asynchronous modes, I implemented HTTP and FastCGI protocols, networking engines myself. Designed high performance services and more.

Should the library be included to Boost?

Unfortunately NO. Two major reasons: - Abuse of static polymorphism where classing object oriented design with virtual functions can do better job. - The scope of the library is way too limited that it brings the question of its usability for real users. I fully acknowledge the huge high quality work the author did - something that kept me reviewing the library and providing the comments, but the library as it is today IMHO doesn't suit Boost Best Regards and Good Luck, Artyom Beilis