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

[Tim Ruehsen]

On Tuesday, February 14, 2017 2:34:27 PM CET Adam Sampson wrote:
> 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 for reporting.

Well, the wget 504 code circumvents most other checks normally done on non-2xx
status codes (incl. body download and saving to WARC files). That seems like
improper handling.

I moved the 504 code to where it belongs (IMO) and created the attached patch.
Please test and report back if it works for you.

Regards, Tim

0001-Fix-504-status-handling.patch
Description: Text Data

signature.asc
Description: This is a digitally signed message part.