Re: [boost] [RFC] Preferred API for a CGI library proposal

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2007-04-05 21:04:40

Darren Garvey wrote:

> This is an initial probe for ideas about an API for [any] upcoming CGI
> library submission.

Hi Darren,

I have some GPL code that does this sort of thing; you're welcome to 
look at it, and I'm not fussy about the license if you want to re-use 
any of it for a Boost submission.  This code has evolved to meet my 
needs, and isn't the sort of thing that you would write if you were 
starting from scratch.  But do have a look at:

http://svn.chezphil.org/libpbe/trunk/include/CgiParams.hh
http://svn.chezphil.org/libpbe/trunk/src/CgiParams.cc

This declares

   CgiParams: public map<string,string>

which seems to me to be the best interface to present for accessing the 
CGI data.  It can initialise itself from GET and POST data, including 
the MIME-like format used for file uploads.

There is also

http://svn.chezphil.org/libpbe/trunk/include/CgiVars.hh
http://svn.chezphil.org/libpbe/trunk/src/CgiVars.cc

which provide access to all the non-parameter variables that the CGI 
spec defines.

There is another version of some of this that I wrote for another 
project in

http://svn.chezphil.org/anyterm/trunk/common/CgiParams.hh
http://svn.chezphil.org/anyterm/trunk/common/UrlEncodedCgiParams.cc

I think this is more "boostified"!  For example, it has a 
get_as<T>(name) method that will lexical_cast the parameter to the 
required type.

I have also used the Apache module API, and have written standalone 
HTTP servers.  If I was doing all this from scratch I'd try to do 
something that would be equally applicable in any of these situations 
(and also things like FCGI as someone else has suggested).  I.e. you 
want to define an 'HTTP Request' object, which has ways of accessing 
the form data, not an explicitly 'CGI' object.  (There is actually an 
HttpRequest class in 
http://svn.chezphil.org/libpbe/trunk/include/HttpRequest.hh, but I 
haven't used it in combination with form data.  There is also a Spirit 
parser for HTTP requests in http://svn.chezphil.org/libpbe/trunk/src/Request.cc.)

> Of particular interest:
> *should GET/POST variables be parsed by default?

So the issue is can you be more efficient in the case when the variable 
is not used by not parsing it?  Well, if you're concerned about 
efficiency in that case then you would be better off not sending the 
thing in the first place.  So I suggest parsing everything immediately, 
or at least on the first use of any variable.

> *how should GET/POST variables be accessed?

As a map<string,string>, or similar.

> *should cookie variables be accessible just like GET/POST vars, or
> separately?

Separately, but again in a map-like name/value thing, e.g.

struct HttpRequest {
   map<string,string> cgi_vars;
   map<string,string> cookies;
   map<string,string> http_headers;
   ...
}

> *should the CGI environment variables each have explicit functions for their
> access, or should (eg.) a generic cgi::get_env() function be used?

I listed them all explicitly in my CgiVars implementation, rather than 
adding another map<string,string> to the HttpRequest.  I think that my 
motivation was to get a compile-time error if I mis-remembered the 
variable name (i.e. vars.remote_host vs. vars["REMOTE_HOST"]).

> *url decoding functions are needed for GET/POST variables.

Internal to your code, of course.  I don't want to see them.

> Should url encoding functions also be provided?

If you want, but in a separate header file.  (And be sure you know 
exactly what encoding you're doing...)

> *how transparent should user code be to internationalization/different
> character sets?

I think that in the case of url-encoded data it's hard to be certain of 
the character set in use.  In the MIME case that data is explicitly 
available, and you should make it accessible to the user.  I think you 
can also get content-type information.  I'm not sure how best to fit 
that into the map<string,string> scheme.  We really need:

class string_with_charset {
   string s;
   charset_t charset;
};

and then your CGI parameters can be map<string,string_with_charset>.   
Or something more complex to handle content-types as well.  Is there a 
Boost wrapper for iconv yet?  What about MIME handling?  I don't think 
either has been doone; maybe you'd like to do those too.

Regards,

Phil.