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
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -