Darren Garvey wrote:
On 17/08/07, Phil Endecott < spam_from_boost_dev@chezphil.org> 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.