[Zope-dev] zope.publisher 3.5 branch has code/behavior not a part of subsequent releases

[Roger Ineichen]

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=5&b: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=1&id=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
> 
>