[Bug-wget] Test-504.py sometimes fails on slow machines

[Adam Sampson]

Hi wget maintainers,

I've just built wget-1.19.1 on several GNU/Linux machines, and found
that Test-504.py fails sometimes on a slow-ish ARMv7 system with Python
3.6.0. Attached are tcpdump traces of the test succeeding and failing on
the same machine, and the log from the failure.

In this test, wget makes three requests against the test HTTP server,
with the first two getting 504 responses and the third succeeding.
Looking at the trace, the 504 responses don't look correct: the server
is operating in pipelined mode, but the 504 response contains no
Content-Length header, so there's no way for wget to know where the body
of the response ends (other than the connection being closed; RFC 2616
section 4.4).

The test succeeds when wget manages to read the headers and body of the
second response, closes the connection in disgust, and opens a new
connection for the final request (which is probably not what the test
author intended). It fails when wget sends its third request before it's
seen the body of the second response, and then tries to parse the body
as the response to the third message; the test output then includes:

  200 No headers, assuming HTTP/0.9

and wget waits until it times out.

I think the right fix here is to have the test server send a proper
Content-Length header in its 504 response?

Thanks,

-- 
Adam Sampson <address@hidden>                         <http://offog.org/>

trace-success
Description: Text document

trace-failure
Description: Text document

Test-504.log
Description: Text document