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
> of baggage?], encryption, authentication, ETags (essentially hashes of
> the content) and conditional fetches -- all of this done with
> to security. This really needs to be done in a way that will fit in
> 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
> 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?
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk