On Aug 24, 2009, at 5:27 PM, Tres Seaver wrote: > -----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.
I'm good with that. My additional constraint would be that self.assertEqual(request.get('QUERY_STRING'), 'a=5&b:int=6') for the same request. Hiding the QUERY_STRING causes us some unpleasant and subtle functional test pain. Passing a QUERY_STRING-free copy to cgi.FieldStorage as you suggest seems like a good way to go to me. Unless someone beats me to it or stops me, I'll plan to make this go in trunk and in the 3.5 branch, and make a 3.5.9 release. (If someone *were* to beat me to it, that would be awesome. I'm kinda swamped.) Thanks Gary _______________________________________________ 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 )