Re: [boost] [GSoC][cgi] Status update.

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2007-08-19 07:57:20

Darren Garvey wrote:
> On 17/08/07, Phil Endecott < spam_from_boost_dev_at_[hidden]> wrote:
>> - Err, actually maybe you do describe the functions for accessing the
>> form data, in the "request meta-data" section at the end of
>> http://cgi.sourceforge.net/html/cgi/ug.html .  But why is this _meta_
>> data, not just "data"?
>
> That's because form/environment data are 'meta-variables', according to the
> CGI specification.

Hmm, you mean rfc3875 section 4.1 "Request Meta-Variables"?  Most of 
the stuff that that section is describing really is meta-data, i.e. 
data-about-the-data; e.g. the IP address of the HTTP client and the id 
of the user.  Section 4.2 describes the contents of the HTML form where 
it's called simply "request data".

At least, that's the case for POST data.  For GET data, it's true that 
the form data is in QUERY_STRING which the spec groups with the 
meta-data, and according to section 4.3.1 "The GET method indicates 
that the script should produce a document based on the meta-variable 
values."  But you're hiding the difference between GET and POST form 
data, and I suggest that you apply common sense rather than just 
copying the spec: call the meta-data meta-data, and call the data data.

>> I will have another look when some more tutorial material is available.

Thanks for the tutorial.

Some more thoughts:

- I think it's important, especially for a Boost library, that you 
supply standard-library-like interfaces where possible.  For example, I 
would like to see the form variables having a std::map-like interface.  
(This would be most easily achieved by actually making them a std::map, 
but if you choose some other implementation structure then you can use 
Boost.Iterator to help with the interface).  This would allow me to 
iterate through them.  At present, I don't think you have a way to get 
the names of all the form variables.

- I don't see a way to use the form data parsers independently.  For 
example, if I write my own code for an Apache module or a stand-alone 
HTTP server, I would like to be able to invoke your parser to decipher 
the urlencoded or multipart/form-data from a string that I supply.  You 
could provide this as an independent header file.

- In the '10 minute intro', you have:
   std::string user_name( req.meta_cookie("user_name") );
   if (!user_name.empty()) { ....
   So is it impossible to distinguish between an empty string and a form 
or cookie value not being set?

- I'm not sure about the idea of sending the response to the request 
object.  I would think of the request object as a const thing.  When I see
   req << "something..."
   I thing that that's something that should only happen when the 
request object is being created e.g. to set the POST data.  In my apps 
I have always had a handler function that returns a response:
   HTTP::Response handle ( const HTTP::Request& req ) { ... }
   but this doesn't fit as well into your arrangement.  Perhaps you need 
a "Message" object to contain a request and the corresponding 
response?  ("Message" is the RFC2616 term for a request/response pair.)

- The term "Response" is normally used rather than "Reply" (e.g. in the 
HTTP spec).

- For multipart/form-data, each form variable has some associated 
metadata; e.g. for a file upload, the filename and possibly the mime 
type are supplied by the browser, and the charset may be indicated for 
other variables.  I don't see any way to get at this.

Regards,

Phil.