[Python-bugs-list] [ python-Bugs-430160 ] CGIHTTPServer.py POST bug using IE

noreply@sourceforge.net noreply@sourceforge.net
Thu, 28 Mar 2002 12:49:53 -0800


Bugs item #430160, was opened at 2001-06-04 20:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=430160&group_id=5470

Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Altis (kasplat)
Assigned to: Nobody/Anonymous (nobody)
Summary: CGIHTTPServer.py POST bug using IE

Initial Comment:
>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"


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

Comment By: Matthew King (kyrrigle)
Date: 2002-03-28 15:49

Message:
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?


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

Comment By: Steve Holden (holdenweb)
Date: 2001-07-17 07:28

Message:
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.

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

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