On Aug 24, 2009, at 6:02 PM, Roger Ineichen wrote:
Hi Tres
Betreff: Re: [Zope-dev] zope.publisher 3.5 branch has code/behavior not a part of subsequent releases
[...]
If I were not already behind, I would investigate to understand the Python 2.6 problem better and see what other frameworks are doing here. I understand from conversations with other engineers that at least some Django developers are accustomed to always having access to the query string on the request object, whether the method were get or post or whatever else.
It is *essential* for correct operation that QUERY_STRING values *not* be admixed with POSTed form values. I don't really care how we resolve your issue, as long as we do not end up in a case where the values in the query string get mingled into the form data: for instance, we could hand a QUERY_STRING-free copy of the environment to the cgi.FieldStorage machinery.
As far as I understand, you are saying that it is essential that posted data and a query string should be separated for processing in python libraries e.g. FieldStorage or so.
But this doesn't mean both values could not end in the request.form dict right?
right, that's what he wants, and that's the pre-Py 2.6 behavior.
Whatever gets done needs to leave the existing test in place::
self.assertEqual(dict(request.form), dict(x='1', y='2'))
for a request whose QUERY_STRING was 'a=5&b:int=6', but which posted the 'x' and 'y' values.
Was this supported before your changes? Is this a new feature you decided to add? What's the reason for this? Can you point me to more infos?
The constraint is an old behavior. The solution in 3.5.8 and 3.5.9 is a pretty big behavior change if you are paying attention to the query string during POSTs. Maybe http://bugs.python.org/issue1817 gives you the information you want? Gary