Re: [boost] [GSoC 2014] Http Server Proposal

Subject: Re: [boost] [GSoC 2014] Http Server Proposal
From: Cory Nelson (phrosty_at_[hidden])
Date: 2014-03-06 12:28:40

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
http://int64.org