Hash: SHA1

Gary Poster wrote:
> Hm.  I sent this from the wrong account, so it didn't make it to the  
> zope-dev list.  I'm also adding an additional bit of war story at the  
> end.
> On Aug 24, 2009, at 11:16 AM, Gary Poster wrote:
>> Hi Tres
>> I made a 3.5.8 release of the zope.publisher 3.5 branch for a reason  
>> unimportant to this email (I backported a change to trunk that was  
>> discussed on the mailing list).  It looks like you made a 3.5.7 with  
>> the following change (omitting tests and the like).
>> 98932    tseaver                 # Python 2.6 notices QS-on-POST,  
>> which breaks BBB for us.
>> 98932    tseaver                 # Suppress that.
>> 98932    tseaver                 if 'QUERY_STRING' in self._environ:
>> 98932    tseaver                     env = self._environ
>> 98932    tseaver                     env['X-POST-QUERY_STRING'] =  
>> env.pop('QUERY_STRING')
>> I can handle adjusting to this change, if it is appropriate, but my  
>> concern is that it is not in trunk or any subsequent major release  
>> (3.6, 3.7, 3.8) of zope.publisher.  Therefore, if I change my code  
>> to use my updated 3.5 release, which I had hoped would be a  
>> conservative update, I have to change in a currently forward- 
>> incompatible way.
>> What's the story here?  Is 3.5.7 a brownbag that needs to have its  
>> changes aborted in a subsequent release in that branch?  Or are  
>> those legitimate changes that need to be forward ported?
>> FWIW, we (Launchpad) also care about this case of a POST with other  
>> pertinent, separate data in the query string, and the behavior you  
>> implement here would be fine if it is necessary for Py 2.6 as your  
>> comment describes.
> Also FWIW, this change breaks many of our forms that were explicitly  
> constructing form actions that included the current query string.  I'm  
> not sure how that could be avoided, although the fix might have been  
> simpler if there were always an X-ORIGINAL-QUERY_STRING or something  
> else.
> 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

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.

- --
Tres Seaver          +1 540-429-0999          tsea...@palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to