Re: [boost] Boost.HTTP ?

From: Michael Dickey (mike_at_[hidden])
Date: 2007-12-10 15:44:48

On Dec 10, 2007, at 6:39 AM, Phil Endecott wrote:

> Dean Michael Berris wrote:
>> 2. There has been initial intent to develop a server-side
>> implementation for HTTP in cpp-netlib which has been dropped because
>> there really is no single best way to implement an HTTP server
>
> Yes, absolutely.  I think that the most useful approach would be to
> provide building-blocks for things like HTTP header and URI parsing [I
> have some Spirit code for this that I'd be prepared to contribute],
> compression [Sebastian Redl seems to have gzip in his IOChains
> proposal, but can it be re-used in an HTTP server without bringing  
> lots
> of baggage?], encryption, authentication, ETags (essentially hashes of
> the content) and conditional fetches -- all of this done with  
> attention
> to security.  This really needs to be done in a way that will fit in  
> to
> thread-per-connection, thread pool, select()-based and other server
> designs, and perhaps also as a CGI program or Apache server module.
>
> How far can the server implementation be decoupled from the
> content-specific stuff, and what interfaces should there be between  
> them?
>
> Michael Dickey wrote:
>>> would it be better to wait and try to merge my library (or at  
>>> least its
>>> functionality) into cpp-netlib?
>
> Far from merging your library into something else, I encourage you to
> see how much you can break it up into smaller chunks and to make it
> compatible with, yet not dependent on, other libraries.

It's definitely moving in that direction.  For example, you can use  
the client-side part of the library without touching any server-side  
stuff, and you can even parse HTTP messages without any networking  
code.  I agree with the approach of breaking pieces out and pushing  
them into a lower-level space like cpp-netlib  over time.

I guess a big question is, does _server-side_ functionality belong in  
Boost?  I think for most cases, you're going to use an external  
packaged server to solve a problem.  However, I think HTTP is a unique  
case in that it is so widely used and for such a wide variety of  
applications, and is simple enough that it often is embedded within  
applications.

> Remember that there's also some GSoC CGI code pending.

Where is that project located?

Take care,
-Mike