[cpp-netlib-devel] Boost.CGI Merger (WAS RE: Nearly time to start merging?)

[Dean M. C. B. <dmb...@fr...>]

Hi Darren!

> -----Original Message-----
> From: cpp...@li... 
> [mailto:cpp...@li...] On 
> Behalf Of Darren Garvey
> Sent: Monday, March 24, 2008 8:33 PM
> To: C++ Networking Library Developers Mailing List
> Subject: [cpp-netlib-devel] Nearly time to start merging?
> 
> Hello all,
> 
> I've sent a couple of random messages to this list before 
> regarding the library under development and the CGI library I 
> started working on for the last GSoC. Because of the huge 
> potential for shared code between the two libraries I really 
> hope we can find some common ground between our efforts, 
> seems silly not to. :)
> 

It's shaping up to be a good year for C++ Network programming! :)

> The CGI library is now in a 
> "mostly-works-but-is-really-ugly-in-places" state - I'm 
> blaming lack of time/practice for that! There are a couple of 
> reasonably major additions to be made when time allows 
> (they're relevant, see the postscript).
> 
> Anyway, there are some cool ideas in the netlib code. I 
> especially like using fusion::map<>s for holding 
> request/response data and of course, the common use of a 
> basic_message<> class.
> 
> Perhaps we can open discussion about where things should and 
> shouldn't align and how best to do that? It'll be summer 
> before I have any real time to spend on this, but I'm really 
> keen that we can make some progress on this.
> 

Like Glyn, I'll try looking into the code. However, I may very well be
concentrating more in helping out Mike with the integration of
pion-net's HTTP code into the library. It would be a dream come true if
somehow the HTTP message code we're developing will be the same one the
CGI library will be using! :)

> Kind regards,
> Darren
> 
> P.S.
> 
> Ideas:
> * add a form_parser class (as part of the public API)
>    - use Boost.Spirit
>    - should read/parse multipart/form-data regardless of request type.
>    - should allow incremental reading/parsing of individual form parts

I like this. :)

We can even do this using the TDD approach where we can write the unit
test(s) independent of any subsystem, and develop the parser(s) to
implement to make the unit tests pass. This way, the compliance to
parsing multipart/form-data can be developed independently.

> * add a param class
>    - holds a boost::iterator_range to the data
>    - convertible to std::string subject to a macro condition 
> (aka. taint mode)
>    - allows easy case-insensitive comparison (possibly using 
> Boost.String_algo? Or the netlib transform meta-functions?)
>    - allows compile-time checking of its source (eg. 
> env/GET/POST) to protect against XSS vulnerabilities.
>    - allows easy lexical casting (eg. param::as<>)
> 

I don't really understand what you mean by this, but if you mean 'param'
in the query string parameter case, then this may be a good idea. I
don't see though if using Boost.Any might make more sense for some
people who want the dynamic-ness (if there's such a thing) of the value.

> * add prepare/consume/commit member functions to 
> network::basic_message<>
>   - functions like in asio::streambuf.
>   - would allow reading data straight from a 
> (asio)(A)SyncReadStream (eg. a socket), without need for buffering
>   - could help with incremental parsing and/or making 
> form_parser class request-agnostic
> 

My suggestion instead of overloading the interface of basic_message<> is
to define adaptors. It should be feasible to have a
'streamed<basic_message<> >' or 'async<basic_message<> >' instance which
would decorate the functionality of the basic_message encapsulated
within the instance. That way it can still be converted into and is
still interface compatible to basic_message<>, but adds functionality
that's typically not inherent in the actual message.

streamed<basic_message<http::message_tag> > streamed_message;
std::string body_line;
getline(body(body_stream), body_line); // synchronously wait for the
first body line to be streamed

async<basic_message<http::message_tag> > async_message;
future<std::string> body_line = body(async_message);
// at some point in time
cout << body_line.get();

This keeps the basic_message<> interface intact and the usage semantics
consistent. What do you think? :D

> P.P.S.
> 
> The basic_message<> class has embedded _source/_destination 
> parameters. These aren't particularly relevant to 
> CGI/FastCGI/SCGI and they imply a close relation between the 
> payload of an HTTP message and its source/destination, which 
> might not always be a 1:1 relationship. I wonder if they 
> should be moved out of the basic_message<> class to some 
> higher-level abstraction?
> 
> 

This may be a good idea, but it's possible to actually use SFINAE or a
cgi::message_tag to specialize on the basic_message<>'s internal
representation while keeping it consistent. For example, you can disable
using SFINAE the interface to accessing (and presence of) the
_source/_destination parameters.

What do you think Darren? I hope these make sense! :)

--
Dean Michael Berris
Software Engineer, Friendster, Inc.
<dmb...@fr...>
+639287291459