Re: [Zope-dev] zope.publisher 3.5 branch has code/behavior not a part of subsequent releases
Hi Gary Betreff: Re: AW: [Zope-dev] zope.publisher 3.5 branch has code/behavior not a part of subsequent releases On Aug 24, 2009, at 6:02 PM, Roger Ineichen wrote: Hi Tres Betreff: Re: [Zope-dev] zope.publisher 3.5 branch has code/behavior not a part of subsequent releases [...] 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. As far as I understand, you are saying that it is essential that posted data and a query string should be separated for processing in python libraries e.g. FieldStorage or so. But this doesn't mean both values could not end in the request.form dict right? right, that's what he wants, and that's the pre-Py 2.6 behavior. 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=5b:int=6', but which posted the 'x' and 'y' values. Was this supported before your changes? Is this a new feature you decided to add? What's the reason for this? Can you point me to more infos? The constraint is an old behavior. The solution in 3.5.8 and 3.5.9 is a pretty big behavior change if you are paying attention to the query string during POSTs. Ah, this sounds good. We often use query string urls for simulate a post request e.g. foo.html?form.action.remove=1id=123 which forces to process the button action in z3c.form within a value 123 for the id field etc. I was afraid that this isn't working anymore if such query values will not longer work as request.form key/values But as far as I understand it's only a problem with POST and query strings and does not affect the above usecase. Maybe http://bugs.python.org/issue1817 gives you the information you want? Thanks a lot Roger Ineichen 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 )
Re: [Zope-dev] zope.publisher 3.5 branch has code/behavior not a part of subsequent releases
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).
98932tseaver # Python 2.6 notices QS-on-POST,
which breaks BBB for us.
98932tseaver # Suppress that.
98932tseaver if 'QUERY_STRING' in self._environ:
98932tseaver env = self._environ
98932tseaver 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.
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 )
Re: [Zope-dev] zope.publisher 3.5 branch has code/behavior not a part of subsequent releases
-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).
98932tseaver # Python 2.6 notices QS-on-POST,
which breaks BBB for us.
98932tseaver # Suppress that.
98932tseaver if 'QUERY_STRING' in self._environ:
98932tseaver env = self._environ
98932tseaver 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=5b:int=6', but which posted the
'x' and 'y' values.
Tres.
- --
===
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software Excellence by Designhttp://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 )
Re: [Zope-dev] zope.publisher 3.5 branch has code/behavior not a part of subsequent releases
Hi Tres Betreff: Re: [Zope-dev] zope.publisher 3.5 branch has code/behavior not a part of subsequent releases [...] 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. As far as I understand, you are saying that it is essential that posted data and a query string should be separated for processing in python libraries e.g. FieldStorage or so. But this doesn't mean both values could not end in the request.form dict right? 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=5b:int=6', but which posted the 'x' and 'y' values. Was this supported before your changes? Is this a new feature you decided to add? What's the reason for this? Can you point me to more infos? Regards Roger Ineichen Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://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 ) ___ 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 )
Re: [Zope-dev] zope.publisher 3.5 branch has code/behavior not a part of subsequent releases
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).
98932tseaver # Python 2.6 notices QS-on-POST,
which breaks BBB for us.
98932tseaver # Suppress that.
98932tseaver if 'QUERY_STRING' in self._environ:
98932tseaver env = self._environ
98932tseaver 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=5b: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=5b: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 )
Re: [Zope-dev] zope.publisher 3.5 branch has code/behavior not a part of subsequent releases
On Aug 24, 2009, at 6:02 PM, Roger Ineichen wrote: Hi Tres Betreff: Re: [Zope-dev] zope.publisher 3.5 branch has code/behavior not a part of subsequent releases [...] 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. As far as I understand, you are saying that it is essential that posted data and a query string should be separated for processing in python libraries e.g. FieldStorage or so. But this doesn't mean both values could not end in the request.form dict right? right, that's what he wants, and that's the pre-Py 2.6 behavior. 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=5b:int=6', but which posted the 'x' and 'y' values. Was this supported before your changes? Is this a new feature you decided to add? What's the reason for this? Can you point me to more infos? The constraint is an old behavior. The solution in 3.5.8 and 3.5.9 is a pretty big behavior change if you are paying attention to the query string during POSTs. Maybe http://bugs.python.org/issue1817 gives you the information you want? 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 )
