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