Boost logo

Boost :

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:

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

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

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, but I
haven't used it in combination with form data. There is also a Spirit
parser for HTTP requests in

> 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.



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