[mod_python] query_vars and form_vars

Jorey Bump wrote:
> Well, I didn't say /discarded/. :) Query parts shouldn't prevent access 
> to a resource (unless desired), but is it even appropriate to return 
> them in an array if the GET method wasn't explicitly used?
 > To clarify my original statement: If the POST method is used, query
 > parts in the URL should *not* be considered part of the form data set.
 > This removes all ambiguity about precedence, substitution, or type
 > conversion.

It's appropriate to make them available in some form, regardless of the 
type of method used.  Whether it's appropriate to return them without 
distinguishing them from POST is, as Grisha says, a matter of 
preference.  By the definition, they should be treated distinctively. 
By common user and programmer expectations, they probably should be 
treated identically.

My own preference at this point is to be able to tell FieldStorage 
explicitly how you want things processed, overriding the current default 
behaviour to only process URI arguments, or POST data, or both.  It's a 
pretty trivial change to the code to do that.

> RFC2616 doesn't prohibit passing arguments in a URI when submitting POST 
> data, but nowhere does it say that they should be processed as form data 
> or supersede any variables passed as POST data. I'd disagree that POST 
> data was originally misdefined; I believe the author was thinking more 
> in terms of scope, where the POST data served to extend a resource. 
> Taken literally, it still doesn't imply that the query parts should be 
> acted upon; they're simply part of the URI. I like the new language, 
> however, because it's less ambiguous.

Absolutely.  RFC2616 doesn't make any connection between query arguments 
and method types.  The query arguments are part of the URI, and 
therefore part of the resource being identified.  Perhaps 'misdefined' 
is too strong a word, I'd be willing to settle for 'poorly defined.' :)