[Using Python 2.0/Sparc Solaris 8, should be
independent of operating system]

cgi.py sometimes ignores the QUERY_STRING when
REQUEST_METHOD is POST.

The CGI specifications says nothing about how programs
should respond to this particular combination. It does
however state that QUERY_STRING should always be set by
the server, regardless of the request method. Since
QUERY_STRING is set, it seems reasonable that the cgi
module should parse it as well and not just ignore it. 

If cgi.py intentionally ignores QUERY_STRING under
these circumstances, I think it should be documented.
:-)

What this means is that if i have a HTML form a'la

<form action="/cgi-bin/some_cgi?foo=foo">
  <input type="text" name="bar">
  <input type="submit">
</form>

and some_cgi is a python script using cgi.py, I should
get both foo and bar set. Currently, the QUERY_STRING
(i.e. "foo=foo") is ignored, and only bar gets set by
cgi.py.

I consider this a "bug" insofar as it is an unexpected
and somewhat inconsistent behaviour. If I e.g. use the
url "/cgi-bin/myprog/session_id=10023" everywhere in my
program, I must suddenly alter it if the URL is used in
a FORM action attribute, and instead insert a hidden
variable called session_id into the form to get cgi.py
to parse it.

The parse() function in cgi.py correctly checks and
appends QUERY_STRING if it is set. But the FieldStorage
read_urlencoded() method does not, and that is the
function that is actually used, not cgi.parse().

The fix should be to add two lines (marked with '>'
below) after the initial assignment to qs in the
read_urlencoded() method of the FieldStorage class so
that it begins:

    def read_urlencoded(self):
        """Internal: read data in query string
format."""
        qs = self.fp.read(self.length)
        if os.environ.has_key('QUERY_STRING'):
            if qs: qs = qs + '&'
            qs = qs + environ['QUERY_STRING']

(the three last lines are new, and identical to the
three lines in the cgi.parse() function which
accomplishes the same task).

Logged In: NO 

Quick check: That "fix" does not work. It duplicates
the QUERY_STRING if you use the GET method. Additional
checks are necessary to ensure correct operation.

Logged In: YES 
user_id=6380

The idea is right, but since nobody volunteered a working
patch, this won't make it into 2.1.  Sorry.  Try again after
2.1!

Logged In: YES 
user_id=88157

This appears to be a somewhat grey area: certainly the CGI
specifications say that the QUERY_STRING must be made
available, but does it make sense to treat QUERY_STRING
data as of equal importance when standard input is present
in a POST method request?

In particular, if QUERY_STRING contains "spam=eggs" and
the standard input contains "spam=chips" then should
FieldStorage().getitem("spam") return ["eggs", "chips"]?

Appealing to the behaviour of other servers is possibly
not the best guide for the cgi library's action, but it
might be instructive to see how other systems have 
approached this problem before changes are made.

Logged In: YES 
user_id=6380

Rejected for lack of time.

I don't have the time to figure out what the right behavior
should be, and the patch appears to be broken.

Steve Holden, perhaps you might want to submit a patch (for
Python 2.3) that does what you think is correct?

Logged In: YES 
user_id=88157

[Left this until the 2.2 dust had cleared. Happy New Year].

I will work on something for inclusion in the next release.
My approach will be to have the new functionality depend on
the provision of additional keyword arguments whose default
values give the existing behavior: I'm not convinced that
CGI does substantially the wrong thing here, and the user
needs to determine whether query string values should be 
merged in or used to override POST input values.