Boost logo

Boost :

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



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