Vin?cius dos Santos Oliveira:

I recently submitted an HTTP server library to Boost Incubator and I'd appreciate feedback: http://rrsd.com/blincubator.com/bi_library/http/?gform_post_id=1460 <http://rrsd.com/blincubator.com/bi_library/http/?gform_post_id=1460>

I intend to submit to Boost later.

This is the library that I developed during GSoC 2014 and I made several improvements (new features, bug fixes, better and extended documentation...) after the end of GSoC. There are a few improvements that I still want to do, but none of them would be a barrier for Boost integration, in my opinion.

This library doesn't have a builtin request router, opposed to several libraries out there, then you can use whatever routing style you wish (tree-based, middleware-based, no router...).

Also, it follows Boost active style, then you can build your own scheduler around it (prioritize requests from certain IPs, defer acceptance of new connections during server high load, reuse prior constructed objects...).

The library follows Asio threading model, then you also choose whether you will handle all requests from the same thread (useful for embedded devices) or multiples ones. The library is fully async, then one thread is not a problem.

It has a powerful and flexible file server API, supporting range-based requests, conditional requests, support for ETags and so on.

After the GSoC, I had the chance to add tests for asynchronous abstractions and now the implementation is much more trustable and stable. The choice to reuse an existing HTTP parser (the Node.js's C parser) also helps a lot.

The simple message-based API helps to support HTTP pipelining, allocation fine tuning and much more. Besides HTTP pipelining, HTTP chunking (and other modern features like 100-continue and HTTP Upgrade) are also supported.

Do you have any users? If you don't have users, I suggest you become the first user by developing an application. -- Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net