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

2017-02-14 Thread 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  
13:52:10.061779 IP 127.0.0.1.50630 > 127.0.0.1.39501: Flags [S], seq 
2424480562, win 43690, options [mss 65495,sackOK,TS val 87000674 ecr 
0,nop,wscale 7], length 0
0x:  4500 003c 2550 4000 4006 176a 7f00 0001  E..<%P@.@..j
0x0010:  7f00 0001 c5c6 9a4d 9082 a332    ...M...2
0x0020:  a002  fe30  0204 ffd7 0402 080a  .0..
0x0030:  052f 8662   0103 0307./.b
13:52:10.061934 IP 127.0.0.1.39501 > 127.0.0.1.50630: Flags [S.], seq 
1266177975, ack 2424480563, win 43690, options [mss 65495,sackOK,TS val 
87000674 ecr 87000674,nop,wscale 7], length 0
0x:  4500 003c  4000 4006 3cba 7f00 0001  E..<..@.@.<.
0x0010:  7f00 0001 9a4d c5c6 4b78 57b7 9082 a333  .M..KxW3
0x0020:  a012  fe30  0204 ffd7 0402 080a  .0..
0x0030:  052f 8662 052f 8662 0103 0307./.b./.b
13:52:10.062085 IP 127.0.0.1.50630 > 127.0.0.1.39501: Flags [.], ack 1, win 
342, options [nop,nop,TS val 87000674 ecr 87000674], length 0
0x:  4500 0034 2551 4000 4006 1771 7f00 0001  E..4%Q@.@..q
0x0010:  7f00 0001 c5c6 9a4d 9082 a333 4b78 57b8  ...M...3KxW.
0x0020:  8010 0156 fe28  0101 080a 052f 8662  ...V.(.../.b
0x0030:  052f 8662./.b
13:52:10.069205 IP 127.0.0.1.50630 > 127.0.0.1.39501: Flags [P.], seq 1:154, 
ack 1, win 342, options [nop,nop,TS val 87000676 ecr 87000674], length 153
0x:  4500 00cd 2552 4000 4006 16d7 7f00 0001  E...%R@.@...
0x0010:  7f00 0001 c5c6 9a4d 9082 a333 4b78 57b8  ...M...3KxW.
0x0020:  8018 0156 fec1  0101 080a 052f 8664  ...V./.d
0x0030:  052f 8662 4745 5420 2f46 696c 6531 2048  ./.bGET./File1.H
0x0040:  5454 502f 312e 310d 0a55 7365 722d 4167  TTP/1.1..User-Ag
0x0050:  656e 743a 2057 6765 742f 312e 3139 2e31  ent:.Wget/1.19.1
0x0060:  2028 6c69 6e75 782d 676e 7565 6162 6968  .(linux-gnueabih
0x0070:  6629 0d0a 4163 6365 7074 3a20 2a2f 2a0d  f)..Accept:.*/*.
0x0080:  0a41 6363 6570 742d 456e 636f 6469 6e67  .Accept-Encoding
0x0090:  3a20 6964 656e 7469 7479 0d0a 486f 7374  :.identity..Host
0x00a0:  3a20 3132 372e 302e 302e 313a 3339 3530  :.127.0.0.1:3950
0x00b0:  310d 0a43 6f6e 6e65 6374 696f 6e3a 204b  1..Connection:.K
0x00c0:  6565 702d 416c 6976 650d 0a0d 0a eep-Alive
13:52:10.069423 IP 127.0.0.1.39501 > 127.0.0.1.50630: Flags [.], ack 154, win 
350, options [nop,nop,TS val 87000676 ecr 87000676], length 0
0x:  4500 0034 d1da 4000 4006 6ae7 7f00 0001  E..4..@.@.j.
0x0010:  7f00 0001 9a4d c5c6 4b78 57b8 9082 a3cc  .M..KxW.
0x0020:  8010 015e fe28  0101 080a 052f 8664  ...^.(.../.d
0x0030:  052f 8664./.d
13:52:10.078331 IP 127.0.0.1.39501 > 127.0.0.1.50630: Flags [P.], seq 1:105, 
ack 154, win 350, options [nop,nop,TS val 87000677 ecr 87000676], length 104
0x:  4500 009c d1db 4000 4006 6a7e 7f00 0001  E.@.@.j~
0x0010:  7f00 0001 9a4d c5c6 4b78 57b8 9082 a3cc  .M..KxW.
0x0020:  8018 015e fe90  0101 080a 052f 8665  ...^./.e
0x0030:  052f 8664 4854 5450 2f31 2e31 2035 3034  ./.dHTTP/1.1.504
0x0040:  2047 6174 6577 6179 2054 696d 656f 7574  .Gateway.Timeout
0x0050:  0d0a 5365 7276 6572 3a20 4261 7365 4854  ..Server:.BaseHT
0x0060:  5450 2f30 2e36 2050 7974 686f 6e2f 332e  TP/0.6.Pyth

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

2017-02-14 Thread 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
From 8b5e487bf38b0dcd8d2fc1002e486f418bf52f20 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tim Rühsen?= 
Date: Tue, 14 Feb 2017 16:20:26 +0100
Subject: [PATCH] Fix 504 status handling

---
 src/http.c | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/src/http.c b/src/http.c
index 898e1841..788a29ff 100644
--- a/src/http.c
+++ b/src/http.c
@@ -3476,7 +3476,7 @@ gethttp (const struct url *u, struct url *original_url, struct http_stat *hs,

 #ifdef HAVE_METALINK
   /* We need to check for the Metalink data in the very first response
- we get from the server (before redirectionrs, authorization, etc.).  */
+ we get from the server (before redirections, authorization, etc.).  */
   if (metalink)
 {
   hs->metalink = metalink_from_http (resp, hs, u);
@@ -3496,7 +3496,7 @@ gethttp (const struct url *u, struct url *original_url, struct http_stat *hs,
   uerr_t auth_err = RETROK;
   bool retry;
   /* Normally we are not interested in the response body.
- But if we are writing a WARC file we are: we like to keep everyting.  */
+ But if we are writing a WARC file we are: we like to keep everything.  */
   if (warc_enabled)
 {
   int _err;
@@ -3556,6 +3556,7 @@ gethttp (const struct url *u, struct url *original_url, struct http_stat *hs,
 pconn.authorized = true;
 }

+/*
   if (statcode == HTTP_STATUS_GATEWAY_TIMEOUT)
 {
   hs->len = 0;
@@ -3568,7 +3569,7 @@ gethttp (const struct url *u, struct url *original_url, struct http_stat *hs,
   retval = GATEWAYTIMEOUT;
   goto cleanup;
 }
-
+*/

   {
 uerr_t ret = check_file_output (u, hs, resp, hdrval, sizeof hdrval);
@@ -3910,8 +3911,8 @@ gethttp (const struct url *u, struct url *original_url, struct http_stat *hs,
   retval = _err;
   goto cleanup;
 }
-  else
-CLOSE_FINISH (sock);
+
+  CLOSE_FINISH (sock);
 }
   else
 {
@@ -3934,7 +3935,14 @@ gethttp (const struct url *u, struct url *original_url, struct http_stat *hs,
 CLOSE_INVALIDATE (sock);
 }

-  retval = RETRFINISHED;
+  if (statcode == HTTP_STATUS_GATEWAY_TIMEOUT)
+{
+  /* xfree (hs->message); */
+  retval = GATEWAYTIMEOUT;
+}
+  else
+retval = RETRFINISHED;
+
   goto cleanup;
 }

--
2.11.0



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

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

2017-02-14 Thread Adam Sampson 
On Tue, Feb 14, 2017 at 04:31:10PM +0100, Tim Ruehsen wrote:
> 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.

Your patch compiles, but doesn't fix the broken test. tcpdump traces
attached of the test succeeding and failing with the patch applied (it's
exactly the same behaviour as before).

Thanks,

-- 
Adam Sampson  
15:55:59.755307 IP 127.0.0.1.53158 > 127.0.0.1.35611: Flags [S], seq 756350460, 
win 43690, options [mss 65495,sackOK,TS val 88271267 ecr 0,nop,wscale 7], 
length 0
0x:  4500 003c 145f 4000 4006 285b 7f00 0001  E..<._@.@.([
0x0010:  7f00 0001 cfa6 8b1b 2d14 fdfc    -...
0x0020:  a002  fe30  0204 ffd7 0402 080a  .0..
0x0030:  0542 e9a3   0103 0307.B..
15:55:59.755434 IP 127.0.0.1.35611 > 127.0.0.1.53158: Flags [S.], seq 
2379597603, ack 756350461, win 43690, options [mss 65495,sackOK,TS val 88271268 
ecr 88271267,nop,wscale 7], length 0
0x:  4500 003c  4000 4006 3cba 7f00 0001  E..<..@.@.<.
0x0010:  7f00 0001 8b1b cfa6 8dd5 c723 2d14 fdfd  ...#-...
0x0020:  a012  fe30  0204 ffd7 0402 080a  .0..
0x0030:  0542 e9a4 0542 e9a3 0103 0307.B...B..
15:55:59.755539 IP 127.0.0.1.53158 > 127.0.0.1.35611: Flags [.], ack 1, win 
342, options [nop,nop,TS val 88271268 ecr 88271268], length 0
0x:  4500 0034 1460 4000 4006 2862 7f00 0001  E..4.`@.@.(b
0x0010:  7f00 0001 cfa6 8b1b 2d14 fdfd 8dd5 c724  -..$
0x0020:  8010 0156 fe28  0101 080a 0542 e9a4  ...V.(...B..
0x0030:  0542 e9a4.B..
15:55:59.759762 IP 127.0.0.1.53158 > 127.0.0.1.35611: Flags [P.], seq 1:154, 
ack 1, win 342, options [nop,nop,TS val 88271268 ecr 88271268], length 153
0x:  4500 00cd 1461 4000 4006 27c8 7f00 0001  Ea@.@.'.
0x0010:  7f00 0001 cfa6 8b1b 2d14 fdfd 8dd5 c724  -..$
0x0020:  8018 0156 fec1  0101 080a 0542 e9a4  ...V.B..
0x0030:  0542 e9a4 4745 5420 2f46 696c 6531 2048  .B..GET./File1.H
0x0040:  5454 502f 312e 310d 0a55 7365 722d 4167  TTP/1.1..User-Ag
0x0050:  656e 743a 2057 6765 742f 312e 3139 2e31  ent:.Wget/1.19.1
0x0060:  2028 6c69 6e75 782d 676e 7565 6162 6968  .(linux-gnueabih
0x0070:  6629 0d0a 4163 6365 7074 3a20 2a2f 2a0d  f)..Accept:.*/*.
0x0080:  0a41 6363 6570 742d 456e 636f 6469 6e67  .Accept-Encoding
0x0090:  3a20 6964 656e 7469 7479 0d0a 486f 7374  :.identity..Host
0x00a0:  3a20 3132 372e 302e 302e 313a 3335 3631  :.127.0.0.1:3561
0x00b0:  310d 0a43 6f6e 6e65 6374 696f 6e3a 204b  1..Connection:.K
0x00c0:  6565 702d 416c 6976 650d 0a0d 0a eep-Alive
15:55:59.759913 IP 127.0.0.1.35611 > 127.0.0.1.53158: Flags [.], ack 154, win 
350, options [nop,nop,TS val 88271268 ecr 88271268], length 0
0x:  4500 0034 2e80 4000 4006 0e42 7f00 0001  E..4..@.@..B
0x0010:  7f00 0001 8b1b cfa6 8dd5 c724 2d14 fe96  ...$-...
0x0020:  8010 015e fe28  0101 080a 0542 e9a4  ...^.(...B..
0x0030:  0542 e9a4.B..
15:55:59.766557 IP 127.0.0.1.35611 > 127.0.0.1.53158: Flags [P.], seq 1:105, 
ack 154, win 350, options [nop,nop,TS val 88271270 ecr 88271268], length 104
0x:  4500 009c 2e81 4000 4006 0dd9 7f00 0001  E.@.@...
0x0010:  7f00 0001 8b1b cfa6 8dd5 c724 2d14 fe96  ...$-...
0x0020:  8018 015e fe90  0101 080a 0542 e9a6  ...^.B..
0x0030:  0542 e9a4 4854 5450 2f31 2e31 2035 3034  .B..HTTP/1.1.504
0x0040:  2047 6174 6577 6179 2054 696d 656f 7574  .Gateway.Timeout
0x0050:  0d0a 5365 7276 6572 3a20 4261 7365 4854  ..Server:.BaseHT
0x0060:  5450 2f30 2e36 2050 7974 686f 6e2f 332e  TP/0.6.Python/3.
0x0070:  362e 300d 0a44 6174 653a 2054 7565 2c20  6.0..Date:.Tue,.
0x0080:  3134 2046 6562 2032 3031 3720 3135 3a35  14.Feb.2017.15:5
0x0090:  353a 3539 2047 4d54 0d0a 0d0a5:59.GMT
15:55:59.766655 IP 127.0.0.1.53158 > 127.0.0.1.35611: Flags [.], ack 105, win 
342, options [nop,nop,TS val 88271270 ecr 88271270], length 0
0x:  4500 0034 1462 4000 4006 2860 7f00 0001  E..4.b@.@.(`
0x0010:  7f00 0001 cfa6 8b1b 2d14 fe96 8dd5 c78c  -...
0x0020:  8010 0156 fe28  0101 080a 0542 e9a6  ...V.(...B..
0x0030:  0542 e9a6.B..
15:55:59.770285 IP 127.0.0.1.35611 > 127.0.0.1.53158: Flags [P.], seq 105:180, 
ack 154, win 350, options [nop,nop,TS val 88271271 ecr 88271270], length 75
0x:  4500 007f 2e82 4000 4006 0df5 7f00 0001  E.@.@...
0x0010:  7f00 0001 8b1b cfa6 8dd5 c78c 2d14 fe96  .

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

2017-02-14 Thread Tim Ruehsen 
On Tuesday, February 14, 2017 4:03:13 PM CET Adam Sampson wrote:
> On Tue, Feb 14, 2017 at 04:31:10PM +0100, Tim Ruehsen wrote:
> > 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.
> 
> Your patch compiles, but doesn't fix the broken test. tcpdump traces
> attached of the test succeeding and failing with the patch applied (it's
> exactly the same behaviour as before).
> 
> Thanks,

Interesting, here wget disconnects after 504 and reconnects. So the missing 
header and/or body doesn't matter.

I'll have a closer look later, just in a hurry.

Regards, Tim


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

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

2017-02-14 Thread Adam Sampson 
On Tue, Feb 14, 2017 at 04:03:13PM +, Adam Sampson wrote:
> Your patch compiles, but doesn't fix the broken test. tcpdump traces
> attached of the test succeeding and failing with the patch applied (it's
> exactly the same behaviour as before).

If it helps: here's a patch to the test server to add a delay after
sending the headers -- this makes it always fail (on the second request)
for me, even on a fast AMD64 machine.

Thanks,

-- 
Adam Sampson  
--- testenv/server/http/http_server.py  2016-02-24 19:40:07.0 +
+++ testenv/server/http/http_server.py  2017-02-14 16:16:02.496607405 +
@@ -8,6 +8,8 @@
 import threading
 import socket
 import os
+import time
+import sys
 
 
 class StoppableHTTPServer(HTTPServer):
@@ -205,6 +207,9 @@
 def Response(self, resp_obj):
 self.send_response(resp_obj.response_code)
 self.finish_headers()
+print("Sleeping after sending headers...", file=sys.stderr)
+time.sleep(3.0)
+print("... continuing", file=sys.stderr)
 if resp_obj.response_code == 304:
 raise NoBodyServerError("Conditional get falling to head")
 raise ServerError("Custom Response code sent.")


signature.asc
Description: PGP signature

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

2017-02-14 Thread Tim Rühsen 
On Dienstag, 14. Februar 2017 16:20:26 CET Adam Sampson wrote:
> On Tue, Feb 14, 2017 at 04:03:13PM +, Adam Sampson wrote:
> > Your patch compiles, but doesn't fix the broken test. tcpdump traces
> > attached of the test succeeding and failing with the patch applied (it's
> > exactly the same behaviour as before).
> 
> If it helps: here's a patch to the test server to add a delay after
> sending the headers -- this makes it always fail (on the second request)
> for me, even on a fast AMD64 machine.

That helps indeed :-)

I don't love to debug unreadable python code...
from what I see, there is a general problem in the python http server code.

Adding the check below make Test-504 survive. But than the next stop is Test-
cookie-401.py, where we have a similar problem.
except ServerError as se:
print(se.__str__())
+if rule_name == "Response" and 
self.rules[rule_name].response_code == 504:
+return(None, None)
return(content, None)

The solution should be to have a Content-Length + body or no body at all for 
error codes. My python knowledge is not good enough to do this work properly. 
Hope that someone else can jump in.

Regards, Tim


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

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

2017-02-16 Thread Tim Ruehsen 
On Tuesday, February 14, 2017 4:20:26 PM CET Adam Sampson wrote:
> On Tue, Feb 14, 2017 at 04:03:13PM +, Adam Sampson wrote:
> > Your patch compiles, but doesn't fix the broken test. tcpdump traces
> > attached of the test succeeding and failing with the patch applied (it's
> > exactly the same behaviour as before).
>
> If it helps: here's a patch to the test server to add a delay after
> sending the headers -- this makes it always fail (on the second request)
> for me, even on a fast AMD64 machine.

Ok, refreshed my (poor) Python knowledge ;-)

Please try this patch, it works out for me even with your additional timing
(thanks for that !)

It fixes 504 handling in src/url.c and additionally adds Content-Length to
error responses that come with a body.

Regards, Tim
From 3de1306d8e6dacabf2ee101cc1974c93dd7768ac Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tim Rühsen?= 
Date: Tue, 14 Feb 2017 16:20:26 +0100
Subject: [PATCH] Fix 504 status handling

* src/http.c: Move 504 handling to correct place
* testenv/server/http/http_server.py: Add Content-Length header on non-2xx
  status codes with a body

Reported-by: Adam Sampson
---
 src/http.c | 20 ++--
 testenv/server/http/http_server.py |  9 +
 2 files changed, 19 insertions(+), 10 deletions(-)

diff --git a/src/http.c b/src/http.c
index 898e1841..788a29ff 100644
--- a/src/http.c
+++ b/src/http.c
@@ -3476,7 +3476,7 @@ gethttp (const struct url *u, struct url *original_url, struct http_stat *hs,

 #ifdef HAVE_METALINK
   /* We need to check for the Metalink data in the very first response
- we get from the server (before redirectionrs, authorization, etc.).  */
+ we get from the server (before redirections, authorization, etc.).  */
   if (metalink)
 {
   hs->metalink = metalink_from_http (resp, hs, u);
@@ -3496,7 +3496,7 @@ gethttp (const struct url *u, struct url *original_url, struct http_stat *hs,
   uerr_t auth_err = RETROK;
   bool retry;
   /* Normally we are not interested in the response body.
- But if we are writing a WARC file we are: we like to keep everyting.  */
+ But if we are writing a WARC file we are: we like to keep everything.  */
   if (warc_enabled)
 {
   int _err;
@@ -3556,6 +3556,7 @@ gethttp (const struct url *u, struct url *original_url, struct http_stat *hs,
 pconn.authorized = true;
 }

+/*
   if (statcode == HTTP_STATUS_GATEWAY_TIMEOUT)
 {
   hs->len = 0;
@@ -3568,7 +3569,7 @@ gethttp (const struct url *u, struct url *original_url, struct http_stat *hs,
   retval = GATEWAYTIMEOUT;
   goto cleanup;
 }
-
+*/

   {
 uerr_t ret = check_file_output (u, hs, resp, hdrval, sizeof hdrval);
@@ -3910,8 +3911,8 @@ gethttp (const struct url *u, struct url *original_url, struct http_stat *hs,
   retval = _err;
   goto cleanup;
 }
-  else
-CLOSE_FINISH (sock);
+
+  CLOSE_FINISH (sock);
 }
   else
 {
@@ -3934,7 +3935,14 @@ gethttp (const struct url *u, struct url *original_url, struct http_stat *hs,
 CLOSE_INVALIDATE (sock);
 }

-  retval = RETRFINISHED;
+  if (statcode == HTTP_STATUS_GATEWAY_TIMEOUT)
+{
+  /* xfree (hs->message); */
+  retval = GATEWAYTIMEOUT;
+}
+  else
+retval = RETRFINISHED;
+
   goto cleanup;
 }

diff --git a/testenv/server/http/http_server.py b/testenv/server/http/http_server.py
index e96f6e82..b222df07 100644
--- a/testenv/server/http/http_server.py
+++ b/testenv/server/http/http_server.py
@@ -204,7 +204,6 @@ class _Handler(BaseHTTPRequestHandler):

 def Response(self, resp_obj):
 self.send_response(resp_obj.response_code)
-self.finish_headers()
 if resp_obj.response_code == 304:
 raise NoBodyServerError("Conditional get falling to head")
 raise ServerError("Custom Response code sent.")
@@ -329,7 +328,6 @@ class _Handler(BaseHTTPRequestHandler):
 except AuthError as se:
 self.send_response(401, "Authorization Required")
 self.send_challenge(auth_rule.auth_type, auth_rule.auth_parm)
-self.finish_headers()
 raise se

 def handle_auth(self, auth_rule):
@@ -362,7 +360,6 @@ class _Handler(BaseHTTPRequestHandler):
 if header_recd is None or header_recd != exp_headers[header_line]:
 self.send_error(400, "Expected Header %s not found" %
 header_line)
-self.finish_headers()
 raise ServerError("Header " + header_line + " not found")

 def RejectHeader(self, header_obj):
@@ -372,7 +369,6 @@ class _Handler(BaseHTTPRequestHandler):
 if header_recd and header_recd == rej_headers[header_line]:
 self.send_error(400, 'Blacklisted Header %s received' %
 header_line)
-

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

2017-02-16 Thread Adam Sampson 
Hi Tim,

On Thu, Feb 16, 2017 at 09:33:08AM +0100, Tim Ruehsen wrote:
> Please try this patch, it works out for me even with your additional timing 
> (thanks for that !)
> It fixes 504 handling in src/url.c and additionally adds Content-Length to 
> error responses that come with a body.

That patch works fine for me now -- I've just built it on my slow ARM
machine, and left the test running in a loop for 20 minutes or so, and
it passed every time. :-)

Thanks very much,

-- 
Adam Sampson  


signature.asc
Description: PGP signature

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

2017-02-16 Thread Tim Ruehsen 
On Thursday, February 16, 2017 12:39:04 PM CET Adam Sampson wrote:
> Hi Tim,
> 
> On Thu, Feb 16, 2017 at 09:33:08AM +0100, Tim Ruehsen wrote:
> > Please try this patch, it works out for me even with your additional
> > timing
> > (thanks for that !)
> > It fixes 504 handling in src/url.c and additionally adds Content-Length to
> > error responses that come with a body.
> 
> That patch works fine for me now -- I've just built it on my slow ARM
> machine, and left the test running in a loop for 20 minutes or so, and
> it passed every time. :-)
> 
> Thanks very much,

Thanks for your report & help !

I also found & fixed a small memory leak that came out with this patch.
The change has been pushed.

Regards, Tim


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