Boost logo

Boost :

Subject: Re: [boost] [GSoC 2014] Http Server Proposal
From: Dean Michael Berris (dberris_at_[hidden])
Date: 2014-03-06 18:00:53

Hi Everyone,

I'm Dean and I'm the co-maintainer of cpp-netlib. I would like to say
thank you first for bringing cpp-netlib into this discussion. I'm
excited that some people still both remember the library and actually
that there was an effort to get it and Pion to become Boost.Network.

The current stable release of cpp-netlib (0.11.0) is actually the last
release where the library lives under the boost::network namespace.
There's a full HTTP/1.0 server implementation there, and there's
significant work to be done to support all of HTTP/1.1.

That said if someone were willing to mentor turning cpp-netlib 0.11.0
into Boost.Network officially, I would very much be willing to help in
that process (at a consultative/adviser/mentor(maybe) role). Because
the code is laid out to be Boost-compliant in 0.11.0, it may be
possible to bring back the Boost.Build shims and have a fork on github
maintained by someone else that actually brings it into Boost library

Unfortunately the project is moving into a direction where we're doing
mostly a rewrite for C++11/C++14 compliance, and as a proving ground
for some of the standardization efforts Glyn Matthews (co-maintainer)
and I would like to push forward with. The next release which we're
hoping to do at the end of 2014 will be moving out of the
boost::network namespace and has a very different code structure from

We've also been trying to minimize the reliance on some Boost
libraries that we use for implementation, for a few reasons -- none of
which is a reflection on Boost's state, but rather more for project
organizational reasons. For example we've recently migrated all our
tests away from Boost.Test and are working with igloo and Google's
Test/Mock libraries. We're also moving to using Asio directly (not the
Boost.Asio version).

However as mentioned if someone would like to take cpp-netlib's 0.11.0
version and turn it into a proper Boost.Network library, I'm more than
happy to make myself available for Hangouts to get the process going
as quickly as possible.

Thank you for your interest, and I wish you have great success in GSoC!

On Fri, Mar 7, 2014 at 4:28 AM, Cory Nelson <phrosty_at_[hidden]> wrote:
> On Fri, Feb 28, 2014 at 7:06 PM, Vinícius dos Santos Oliveira
> <vini.ipsmaker_at_[hidden]> wrote:
>> Hi guys,
>> I'm interested in develop an asynchronous HTTP server for Boost as part
>> of GSoC.
>> The design would be inspired from Node.js without the facilities or
>> inspirations that were created to overcome JavaScript quirks and
>> limitations.
>> The library would be modular to the point where you can use only small
>> parts of it and you could also replace components that you don't like.
>> The library should have a small overhead to be used on embedded
>> projects, but the modular design will allow you to use higher
>> abstractions when such concerns don't exist. Of course it's difficult to
>> find the "right" answer to the problem, then I'll limit the
>> higher-abstractions to "proven" techniques and avoid controversial
>> features. I hope to give more details in the middle of the next week.
>> The library will not be about writing template-driven web pages, but it
>> will be about HTTP and you will be able to do things like video live
>> stream via HTTP (try to do that with Django or PHP). I also intend to
>> allow a efficient use in multithreaded environment with high-load of
>> data (although network applications are usually I/O bound and not CPU
>> bound). Of course it'll be possible to use WebSocket with this library
>> too.
>> Another thing I want to allow is to mock HTTP requests and transparently
>> replace parts of the stack without affecting already written code. The
>> purpose of this feature is to allow other transport mechanism such as
>> FastCGI and also provide a future-proof approach by better allowing
>> HTTP/2.0 when released.
>> I would implement such library on top of Boost ASIO and I'd include
>> facilities that I'm sure would work on long-term. Because the success of
>> such project is very sensible to the chosen design, I'd limit its scope
>> to things that I know it will work long-term. If the implementation
>> project end up being too small, ...
> Making a good, correct HTTP 1.1 parser is very non-trivial -- this is
> actually a pretty ambitious project for GSOC. I'd recommend condensing
> your idea as much as possible and working on it in cleanly separable
> steps. Don't get distracted by Websockets and FastCGI!
> Please make the parser I/O agnostic and non-blocking (push bytes in,
> get a chunk of a http message as a result or request for more data) --
> it'll be simpler to test and will allow porting to lower-level I/O
> when asio becomes too slow.
> --
> Cory Nelson
> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at