Author jeff.allen
Recipients jeff.allen
Date 2014-01-07.00:19:11
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1389053951.39.0.997653737297.issue20155@psf.upfronthosting.co.za>
In-reply-to
Content
When I run:
    start python -m test.test_httpservers

test_request_line_trimming reports ERROR, and the test hangs at test_version_none. If I run a copy of the test in which the latter test is skipped with @unittest.skipIf(sys.platform == "win32", "..."), the error report is:

======================================================================
ERROR: test_request_line_trimming (__main__.BaseHTTPServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_httpservers.py", line 122, in test_request_line_trimming
    res = self.con.getresponse()
  File "C:\Python33\lib\http\client.py", line 1131, in getresponse
    response.begin()
  File "C:\Python33\lib\http\client.py", line 354, in begin
    version, status, reason = self._read_status()
  File "C:\Python33\lib\http\client.py", line 316, in _read_status
    line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
  File "C:\Python33\lib\socket.py", line 297, in readinto
    return self._sock.recv_into(b)
ConnectionResetError: [WinError 10054] An existing connection was forcibly closed by the remote host

This is essentially the same for Python 2.7.6 and for the current development tip of Jython 2.7b1+, which is actually where the problem first manifested.

My machine is running 64-bit Windows 7 SP1, recently re-installed to a new, empty disk.

Careful testing, elaborating the failing tests, shows that what is sent in PUT and GET operations is not quite what is received. Something tampers with the connection between the client and the server. (Identical traffic where the verbs are not PUT and GET arrives as sent.) Something fiddles with the forward message, for example "correcting" the spurious \n in test_request_line_trimming to a full \r\n, and holding back the payload of a PUT even when it was in the first packet. On the reverse path, it appears to act on the error response itself by closing the connection, without passing it to the client.

Disabling the firewall (Windows Firewall and a commercial one), with the network cable unplugged, makes no difference. Nor does stopping anti-virus, anti-phishing, parental controls, etc.. However, stopping the Windows Basic Filtering Engine (BFE), makes the regression test run without error. Stopping the BFE takes out several dependent services, including Windows Firewall, but it seems likely the BFE itself is the culprit.

Although the cause lies in the platform, not in Python, it seems to me still an "issue" for Python that the tests fail on a common platform practically out of the box. I'll work on this in the context of the Jython test and report back here.
History
Date User Action Args
2014-01-07 00:19:11jeff.allensetrecipients: + jeff.allen
2014-01-07 00:19:11jeff.allensetmessageid: <1389053951.39.0.997653737297.issue20155@psf.upfronthosting.co.za>
2014-01-07 00:19:11jeff.allenlinkissue20155 messages
2014-01-07 00:19:11jeff.allencreate