-----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 tseaver@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-----