[mod_python] query_vars and form_vars

Gregory (Grisha) Trubetskoy wrote:

> 
> This behaviour is part of mod_python.util.FieldStorage class, which is a 
> little convenience tool. Protocol compliance is of little or no 
> relevance here, since you're free not to use it and process input data 
> using your own code or, for example using Python standard library 
> FieldStorage.
> 
> Also, if I remember it correctly, most relevant RFC's tend to focus on 
> the behaviour of the browser (e.g. the user should be warned before a 
> POST if you hit reload, but not for GET), and there is nothing there 
> about how the form variables should appear to an application.
> 
> As to why it processes GET and POST together and GET wins - that's a 
> matter of personal preference. I find it convenient to be able to 
> override variables in a form by appending them to the URL, and I think 
> most user-friendly applications should behave this way, because IMHO 
> ability to tinker with the URL is a good thing.
> 
> Some people believe that this should not be allowed because it enables a 
> user to alter hidden POST variables, which would otherwise be difficult, 
> but this seems to me like a silly argument. There are much more certain 
> ways of ensuring that hidden variables have not been modified, e.g. an 
> MD5 or SHA signature passed along.

It all seems harmless enough. If a programmer decides to use this 
method, it will be necessary to check if the result is a string or a 
list and act accordingly.

If the need arises to distinguish between the query parts and the POST 
data, that's easy enough with cgi.parse_qs(req.args) or 
util.parse_qs(req.args). Is there a similar function that returns only 
POST data?

For applications not designed this way, what is the worst that could 
happen? String operations would break when a list is returned, like

  name = name.upper()

If there is an exploit, it's no different than any other user input 
validation issue, regardless of the method used (POST or GET).