-----BEGIN PGP SIGNED MESSAGE----- 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 machinery. 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. - -- =================================================================== Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKkwXA+gerLs4ltQ4RAhVKAKDY5LuTUshFf1ihKTQXpJjyxvIeeACglpu8 FZSMcnQjaiOyax9ziOAlFNE= =qJS/ -----END PGP SIGNATURE----- _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )