Boost logo

Boost :

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

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

Where is that project located?

Take care,

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