[mod_python] query_vars and form_vars

Byron Ellacott wrote:
> Jorey Bump wrote:
> 
>> I don't know what causes this behaviour. Since only a POST request is 
>> sent, not a GET, I would expect any arguments in the URL to be ignored 
>> and only variables in the message body to be recognized.
> 
> 
> The specification makes a distinction between URL encoded arguments (a 
> query fragment) and POST data (just plain old data).  The URL arguments 
> form part of the resource request, and should be treated as effectively 
> the same as a path fragment, that is, only used to specify which 
> resource it is the user is requesting.  POST data is misdefined in 
> RFC2616 as "a new subordinate of" the requested resource, and corrected 
> in http://purl.org/NET/http-errata to be "data processed by" the 
> requested resource.
> 
> So, in essence, the protocol definition makes a clear distinction 
> between the roles of query fragments and POST data, but that distinction 
> is lost when dealing with the vast bulk of web programming libraries out 
> there, including mod_python's FieldStorage class.  The correct 
> (as-per-specification) behaviour would be to distinguish between query 
> arguments and POST data values.
> 
> It is quite easy to argue that long convention makes the specification's 
> differentiation irrelevant, however.  But in neither world should part 
> of the URL be /ignored/. :)

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.

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.