[New-bugs-announce] [issue10319] SocketServer.TCPServer truncates responses on close (in some situations)

jrodman2 report at bugs.python.org
Fri Nov 5 06:38:39 CET 2010

New submission from jrodman2 <jrodman at pythontracker.spamportal.net>:

Behavior exists in at least Python 2.5 through 3.1.

The issue regards the socketserver's handling of the tcp sockets it works with.  On object reaping, the sockets are properly closed (in some versions explicitly, in others implicitly).  However, closing a socket with unread data will in some operating systems prevent sent data from being sent.  Notably this occurs on Linux and Windows (I tested on Debian testing x86_64 and Windows Vista x86).

Extensive tcpdump sessions and a lot of head scratching finally clarified the issue.  The OS would send an RST packet after just the first bit of data handed over to the socket implementation, in typical cases meaning hte first line of text python is writing would be sent to the client, but no more, causing invalid HTTP replies.

Here is a change to force the socket to be drained on close.  It is of no matter that more data may arrive on the socket post-drain, because the socket implementation in the operating system should be happy to send off what was already queued by the python program at this point.

Testing bears this out, across many platforms here.

Here is one way to accomplish this in python 2.x, in 3.x the equivalent file is socketserver.py, but has the same issue.  It lacks the explicit request.close() call, bgut this seems a matter of aesthetics.

Note that the use of select.select() is documented by Linux to be unsafe for this purpose in some circumstances, and may be on other platforms as well.

I sort of would rather have sockets have a socket.drain() function which is known to be safe and correct for this type of socket programming issue.  If that would be more appropriate, please suggest.

       Under  Linux, select() may report a socket file descriptor as "ready for reading", while nevertheless a subsequent
       read blocks.  This could for example happen when data has arrived but upon examination has wrong checksum  and  is
       discarded.   There may be other circumstances in which a file descriptor is spuriously reported as ready.  Thus it
       may be safer to use O_NONBLOCK on sockets that should not block.

--- SocketServer.py.orig	2010-11-04 21:36:23.000000000 -0700
+++ SocketServer.py	2010-11-04 21:38:19.000000000 -0700
@@ -445,6 +445,13 @@
     def close_request(self, request):
         """Called to clean up an individual request."""
+        # drain socket
+        request.setblocking(0)
+        try:
+            while True:
+                request.recv(4096)
+        except socket.error, e:
+            pass

messages: 120469
nosy: jrodman2
priority: normal
severity: normal
status: open
title: SocketServer.TCPServer truncates responses on close (in some situations)
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1

Python tracker <report at bugs.python.org>

More information about the New-bugs-announce mailing list