From the readme included in the zip:
This set of files shows a bug that occurs when doing 
POST requests via the CGIHTTPServer.py module in 
Python 2.1 The testpost.html file when accessed via 
Internet Explorer 5.5 from webserver.py should show 
this bug. On short POST requests IE will end up doing 
a second POST and then displaying an error message 
while longer POSTs will be followed by a second POST 
and then a GET.

The problem appears to be specific to the interaction 
of IE and the handling of windows sockets in Python in 
the CGIHTTPServer.py module which relies on 
BaseHTTPServer.py, SocketServer.py...

posttestwebserver.py is currently setup to use 
C:\tmp\testpost as the document root, so either move 
the "testpost" folder to C:\tmp or change the 
directory to wherever the testpost folder is located. 
Start the server using the .bat file and bring 
up .html page with something like:
  http://localhost/testpost.html

The bug should occur when you try:
  Test short CGI response with POST
or
  Test long CGI response with POST

The other requests should work fine. The bug will 
occur regardless of whether IE is set to use HTTP/1.0 
or HTTP/1.1. The bug doesn't appear to occur when 
going through a simple proxy. You can also get the bug 
to occur using a remote IE client (either on a LAN or 
over the Net). In addition, it doesn't appear to 
matter whether running with unbuffered binary pipes 
(python -u) or not. I also tested against my modified 
CGIHTTPServer.py See the bug I posted at:
http://sourceforge.net/tracker/?
func=detail&atid=105470&aid=427345&group_id=5470

My configuration:
Windows 2000 Pro, SP2
AMD 1.2GHz
256MB RAM
ActiveStatet Python 2.1 (build 210)
Internet Explorer 5.5 (5.50.4522.1800)

ka
---
Mark Lutz said:
"FWIW, I noticed today (in between lecturing a class) 
that on Windows, Python actually uses a special Python-
coded socket.py library module, not the standard C-
coded socket extension module.  socket.py lives in the 
library directory; it does unique things for closes 
and deletes that may not make sense in all cases 
(e.g., the makefile call generates a class instance, 
not a true file object).  It may also be trying to 
close the underlying socket twice.  I don't have"

Logged In: YES 
user_id=88157

Please note that I have observed this behavior on Windows
98 using Python 2.0 (#8, Mar  7 2001, 16:04:37) [MSC 32 bit 
(Intel)] using the same build of IE, so it is not a Win2k-
specific problem.

Logged In: YES 
user_id=247536

it appears that IE is sending 2 extra bytes ('\r\n') after 
the request data.  and if you don't read those two extra 
bytes off, the window's socket handling gets messed up.

the result is that a partial response is returned and the 
socket closed.  IE tries to recover by re-POST'ing (which 
is behavior specified in the HTTP/1.1 RFC)... only they 
seem to add an embedded NULL the second time through, and 
the original socket problem happens again anyway.

Try reading an extra 2 bytes from the rfile before sending 
your response and the problem should go away.

not sure what the real fix for this should be?

Logged In: YES 
user_id=6380

Steve, I'm assigning this bug to you. Feel free to check in
a fix if you think one exists (as long as it doesn't break
on Unix).

Logged In: YES 
user_id=88157

This patch appears to fix the basic CGIHTTPServer behavior, 
at least for Unix and Wiondows platforms, but I'm not yet 
confident of its robustness in the face of Forking or threading 
mixin code. More later ...

Logged In: YES 
user_id=88157

Should be fixed by patch 654910 committed today.

Logged In: YES 
user_id=23630

The patch might cause the server to loop endlessly, if the
client has closed the connection. I suggest to change the
patch as follows:

   while select.select([self.rfile], [], [], 0)[0]:
-    waste = self.rfile.read(1)

to

   while select.select([self.rfile], [], [], 0)[0]:
+    if not self.rfile.read(1): break

Maybe this is necessary for the Windows case as well ...

Logged In: YES 
user_id=6380

Raymond, can you fix this? Seems simple enough...

Logged In: YES 
user_id=80475

Applied to both the Unix and Windows flavors.
Closing bug.  Hopefully it stays dead this time.

See Lib/CGIHTTPServer.py 1.31