[Python-bugs-list] [ python-Bugs-427345 ] CGIHTTPServer fix for Windows

noreply@sourceforge.net noreply@sourceforge.net
Fri, 10 Aug 2001 12:18:07 -0700


Bugs item #427345, was opened at 2001-05-25 10:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427345&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
>Priority: 3
Submitted By: Kevin Altis (kasplat)
Assigned to: Guido van Rossum (gvanrossum)
Summary: CGIHTTPServer fix for Windows

Initial Comment:
CGIHTTPServer.py in the Python 2.1 library needs two 
changes to the popen2 section in order to support 
binary data and to avoid buffering problems under 
Windows. The complete code block is shown at the end 
of this message. The two changed lines are:
cmdline = "%s -u %s" % (interp, cmdline)
fi, fo = os.popen2(cmdline, 'b')

I've tested this under Windows 2000 Pro and binary 
file uploads now work, however more extensive tests 
should probably be done.

It appears there is another socket-related problem 
and/or end-of-line conversion error that occurs when 
using Internet Explorer 5.x and BASEHTTPServer with 
CGIHTTPServer on the same machine. I'm still 
investigating that issue.

Finally, I have done a small rewrite of 
CGIHTTPServer.py to simplify subclassing it to support 
running CGIs in any or all directories and using other 
file extensions such as .cgi. The maintainer for the 
current file should email me about the changes to see 
whether they want to update the official library file. 
I didn't post it here since it needs more tweaking

ka
---
CGIHTTPServer.p fixes...
elif self.have_popen2:
    # Windows -- use popen2 to create a subprocess
    import shutil
    os.environ.update(env)
    cmdline = scriptfile
    if self.is_python(scriptfile):
        interp = sys.executable
        if interp.lower().endswith("w.exe"):
            # On Windows, use python.exe, not 
python.exe
            interp = interp[:-5] = interp[-4:]
        cmdline = "%s -u %s" % (interp, cmdline)
    if '=' not in query and '"' not in query:
        cmdline = '%s "%s"' % (cmdline, query)
    self.log_error("command: %s", cmdline)
    try:
        nbytes = int(length)
    except:
        nbytes = 0
    fi, fo = os.popen2(cmdline, 'b')
    if self.command.lower() == "post" and nbytes > 0:
        data = self.rfile.read(nbytes)
        fi.write(data)
    fi.close()
    shutil.copyfileobj(fo, self.wfile)
    sts = fo.close()
    if sts:
        self.log_error("CGI script exit status %#x", 
sts)
    else:
        self.log_error("CGI script exited OK")


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-09 06:14

Message:
Logged In: YES 
user_id=6380

Reopening -- not that I have time for this. :-(

Note that that patch is in socket.py.

If this really is a work-around, I'd like to understand why.

----------------------------------------------------------------------

Comment By: Steve Pike (oztourer)
Date: 2001-08-09 05:27

Message:
Logged In: YES 
user_id=120658

To further elaborate on the problems with POST on Windows 
95: without having reached any real understanding of the 
problem I have found a tolerable workaround. By modifying 
the default _rbufsize for class _fileobject in socket.py I 
can get any POSTs with text length less than _rbufsize to 
work. Here is the mod:

<pre>
class _fileobject:
    def __init__(self, sock, mode, bufsize):
        self._sock = sock
        self._mode = mode
        if bufsize < 0:
            bufsize = 512
        # SP 9 Aug 2001: default _rbufsize is too small, 
crashing CGIHTTPServer on POST's
        # This fix still only allows pages of less than 
given buffer size to be updated,
        # so the real fix has still to be discovered.
        #self._rbufsize = max(1, bufsize)
        self._rbufsize = max(16*1024, bufsize)
        self._wbufsize = bufsize
        self._wbuf = self._rbuf = ""
</pre>

-- StevePike

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-07 12:59

Message:
Logged In: YES 
user_id=6380

I agree that this is a laudable goal, but I don't have the
time to spend to work on this.  Please upload a patch to the
SF patch manager and assign it to me and I'll look at it.

In the mean time, I've applied the two small suggestions and
will close this bug report.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-29 09:29

Message:
Logged In: NO 

I want to elaborate on the second-to-last 
paragraph in this report.  CGIHTTPServer 
in 2.1 and 2.0 is apparently broken for 
POST requests (only) to CGI scripts, when
running locally on Windows with an IE client.

The details: there is a problem with 
the combination of a CGIHTTPServer and 
Intenernet Explorer both running locally 
on Windows (with server name "localhost").
In this setup, POST requests to CGI scripts
fail, but GET requests to the exact same 
script work fine.  That is, a form with 
method=GET, or a URL with an appended 
query string, both work ok.

In POST mode, the CGI script gets proper
data in the input stream, and generates 
a correct reply stream (which is in fact 
identical to the output generated for 
quivalent GET requests).  So, somewhere 
between CGIHTTPServer and IE, the data 
seems to be dropped or munged.  The same
thing happens of you force CGIHTTPServer 
to use execfile() to launch the script, 
instead of os.popen2.

I've also observed that endline conventions 
seem to be irrelevant to the problem; using 
\n or \r\n makes no difference in both the 
input and reply streams.  I've also been 
told that the problem may not exist in 
Netscape clients.

Since CGIHTTPServer is a very nice way to test
CGI scripts (all you need is a standard Python
install), this seems important.  It would also 
be nice if the directory assumptions in that 
module were more customizable, but that's just
a wish.

--Mark Lutz


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427345&group_id=5470