bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] [Bug-Wget] Patch Test-proxied-https-auth.px


From: Tim Rühsen
Subject: Re: [Bug-wget] [Bug-Wget] Patch Test-proxied-https-auth.px
Date: Fri, 31 Oct 2014 21:45:03 +0100
User-agent: KMail/4.14.2 (Linux/3.16-3-amd64; KDE/4.14.2; x86_64; ; )

Am Freitag, 31. Oktober 2014, 16:32:28 schrieb Giuseppe Scrivano:
> Darshit Shah <address@hidden> writes:
> > Ever since the Perl tests have been ported to the parallel test
> > harness, Test-proxied-https-auth.px has always failed for me. In a
> > prior thread, we'd identified the problem as a race between the HTTPS
> > server being set-up and Wget sending the request.
> > 
> > The test was already using `sleep 1` to eliminate this race. I've
> > bumped this up to 2 seconds. Now on my machine, the test no longer
> > fails.
> > 
> > If everyone is okay with this change, lets push it. If someone wants
> > to change the number, please speak up.
> 
> the problem seems to be that sometimes wget registers a connection as
> persistent even though it should not that.
> 
> Before I prepare a patch, I would like to check with you all as you
> already spent some time on this issue.
> 
> This code dates back to 2003, but I am not sure we should check for the
> "Connection" response header only if there is a Content-Length specified
> (that is contlen != -1).
> 
> With this patch I could run the test in a loop without failures.
> 
> (while true; do make check -C tests TESTS=Test-proxied-https-auth || exit;
> done)
> 
> diff --git a/src/http.c b/src/http.c
> index 844f800..cded2de 100644
> --- a/src/http.c
> +++ b/src/http.c
> @@ -2287,7 +2287,7 @@ read_header:
>      }
> 
>    /* Check for keep-alive related responses. */
> -  if (!inhibit_keep_alive && contlen != -1)
> +  if (!inhibit_keep_alive)
>      {
>        if (resp_header_copy (resp, "Connection", hdrval, sizeof (hdrval)))
>          {
> 

Did you get my email from today 09:43:19 ?
I fixed up the test (after reading how a *transparent* HTTPS proxy works).

The valgrind messages are definitely a (known) valgrind / openssl issue. They 
result in an failing test (with valgrind) because openssl accesses 
uninitialized memory by purpose.

The same is true for the python test 'Test--https.py'.

Either we leave valgrind testing out for these or we create a suppression 
list. But this might change with each openssl version...

As Daniel mentioned, there of course these MITM HTTPS proxys. We need a test 
for such a scenario as well. Maybe we should move the test HTTPS proxy server 
code into HTTPServer.pm. Maybe an interesting job for Pär Karlsson !?

Tim

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]