gary.poster at gmail
Aug 24, 2009, 5:27 PM
Post #4 of 6
(700 views)
Permalink
|
|
Re: zope.publisher 3.5 branch has code/behavior not a part of subsequent releases
[In reply to]
|
|
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 [at] zope
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 )
|
