We just upgraded Python to 2.6 on some of our servers and a number of
our CGI scripts broke because the cgi module has changed the way it
handles POST requests.  When the 'action' attribute was not present in
the form element on an HTML page the module behaved as if the value of
the attribute was the URL which brought the user to the page with the
form, but without the query (?x=y...) part.  Now FieldStorage.getvalue()
is giving the script a list of two copies of the value for some of the
parameters (folding in the parameters from the previous request) instead
of the single string it used to return for each.  I searched the python
mailing list looking for a discussion of the proposal to impose this
change of behavior, and perhaps I wasn't using the right phrases in my
search, but I didn't find anything.  I didn't get many responses when I
asked for pointers to this discussion, but the few I did get were from
people who were as surprised as we were.  It's not clear to us (or to
those who responded on the mailing list) that the applicable RFCs
provide completely clear and unambiguous guidance as to which behavior
is correct, but even if the new behavior is correct, it is unusual to
have changes to the library which break existing code introduced without
any discussion of the impact, or transition period, or options to
preserve the previous behavior.  For what it's worth, it appears that
Perl and PHP (which probably account for the bulk of non-Python CGI
scripts in the wild) both behave the way the pre-2.6 cgi module did.  We
have a workaround (modify all our CGI scripts to explicitly set the
action attribute without the parameter suffix), but I was asked by one
of the regulars on the mailing list to file a bug report here, so I'm
complying with that request.

It appears that the breaking change was introduced with
http://svn.python.org/view?rev=64447&view=rev in connection with
http://bugs.python.org/issue1817.

See
http://mail.python.org/pipermail/python-list/2009-February/529130.html
for repro instructions.

The issue of distinguishing between query-originating parameters and
form-originating parameters has been around for a very long time, and
in my own work, especially where the cgi module has been used, I've
been careful to distinguish between the two types and to merge them
only if this is desired.

See these messages for historical context around this issue:

http://mail.python.org/pipermail/web-sig/2003-October/000060.html
http://mail.python.org/pipermail/web-sig/2003-October/000224.html
http://mail.python.org/pipermail/web-sig/2003-November/000257.html

Here's an old reference to the code which was changed in the cgi module:

http://mail.python.org/pipermail/web-sig/2003-November/000322.html

To summarise, a previous patch for this issue was never submitted
because of the risk of breaking existing code.

Just to make life interesting, someone went in and changed all the URLs for messages in the Python mailing list.  Here's the new URL for the message which contains the repro instructions:

http://mail.python.org/pipermail/python-list/2009-February/1192951.html

The URL which represents the reported behavior in that message now points to a machine which has been upgraded to Python 2.7, not 2.6 as reported in the repro instructions, but the behavior is still the same.  Of course, these instructions won't be useful forever, because the Debian server which is running Python 2.5 (to show the previous behavior) will (I assume) eventually move on to a later version of Python itself.  But for now the repro instructions are still valid.