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

[Gary Poster]

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.

>
> Gary