Issue430160
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2001-06-05 00:09 by kasplat, last changed 2022-04-10 16:04 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
windows posttest bug.zip | kasplat, 2001-06-05 00:09 | zip file containing html and CGIs to reproduce bug | ||
patch001.txt | holdenweb, 2002-08-16 02:25 | First-round fix for IE POST bug |
Messages (9) | |||
---|---|---|---|
msg4952 - (view) | Author: Kevin Altis (kasplat) | Date: 2001-06-05 00:09 | |
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" |
|||
msg4953 - (view) | Author: Steve Holden (holdenweb) * | Date: 2001-07-17 11:28 | |
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. |
|||
msg4954 - (view) | Author: Matthew King (kyrrigle) | Date: 2002-03-28 20:49 | |
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? |
|||
msg4955 - (view) | Author: Guido van Rossum (gvanrossum) * | Date: 2002-08-05 14:57 | |
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). |
|||
msg4956 - (view) | Author: Steve Holden (holdenweb) * | Date: 2002-08-16 02:25 | |
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 ... |
|||
msg4957 - (view) | Author: Steve Holden (holdenweb) * | Date: 2003-01-08 18:58 | |
Logged In: YES user_id=88157 Should be fixed by patch 654910 committed today. |
|||
msg4958 - (view) | Author: Deleted User weoweo (weoweo) | Date: 2003-06-24 20:58 | |
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 ... |
|||
msg4959 - (view) | Author: Guido van Rossum (gvanrossum) * | Date: 2003-06-27 10:59 | |
Logged In: YES user_id=6380 Raymond, can you fix this? Seems simple enough... |
|||
msg4960 - (view) | Author: Raymond Hettinger (rhettinger) * | Date: 2003-06-29 05:07 | |
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 |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-10 16:04:06 | admin | set | github: 34582 |
2001-06-05 00:09:04 | kasplat | create |