durusmail: quixote-users: GET, POST, QUERY_STRING and FieldStorage
GET, POST, QUERY_STRING and FieldStorage
2003-03-22
2003-03-22
2003-03-25
Re: GET, POST, QUERY_STRING and FieldStorage
2003-03-25
2003-03-25
GET, POST, QUERY_STRING and FieldStorage
Greg Ward
2003-03-25
On 21 March 2003, Jason Sibre said:
> The idea I like (and I admit, I haven't thought the through very far, so
> maybe it isn't practical), is a hodge-podge of other web environments I've
> worked with (PHP, ColdFusion, and MS's ASP):
>
> I'd like to see something like:
>
> REQUEST.COOKIES[]     - contains cookie data
> REQUEST.QUERYSTRING[] - always contains querystring data, whether GET or
> POST
> REQUEST.FORM[] - only contains POSTed data if it exists.

That much makes sense (except for the UPPERCASE NAMES -- Python is a
quiet, friendly language, there's no need to shout), assuming Quixote
even should support the practice of mixing query variables in the URL
(GET) and in the request body (POST).

> and a convenience accessor of:
>
> REQUEST[]

No bloody way.  That's the first step on the road to Zope and the
__getitem__() method from beyond the ninth circle of hell.  Also,
conflating cookies and form data is (IMHO) a serious conceptual error.
They do not have the same purpose, and they should not be used for the
same things.

Here's a strawman API:

  request.get_form_var('name')      # look in POST data, then GET data
  request.form['name']              # ditto (maaaaaybe)

For implementation, change 'request.form' from a dictionary to an
instance of a new class, say HTTPQuery.  This instance would contain:

  * the original $QUERY_STRING provided by the HTTP server
    (eg. "?name=dennis&age=37")

  * the parsed version of query string (basically a dictionary like
    {'name': 'dennis', 'age': '37'}, but it's more complex than that:
    see below)

  * the parsed version of the POSTed query from stdin (or analogous,
    if this isn't a plain CGI environment)

Of course a simple dictionary isn't good enough for handling
"?name=dennis&name=arthur&age=37", which could be the result of an
accident in form design, deliberate form design, a multiple selection
list, or a broken/malicious client.  The standard 'cgi' module's
FieldStorage class handles this in maybe the worst possible way, by
providing values of unpredictable type.  This is a good opportunity to
ditch Quixote's use of FieldStorage, which I believe is the only thing
it uses from the standard 'cgi' module.  I'm just not sure what to
replace it with.  ;-(

        Greg
--
Greg Ward                          http://www.gerg.ca/
"Very funny, Scotty.  Now beam my *clothes* down."

reply