libwww-perl / lwp-protocol-https Goto Github PK

Currently a user will get this if they have Crypt::SSLeay installed, but
not IO::Socket::SSL:

$ perl -MLWP::UserAgent -MMozilla::CA -E
'LWP::UserAgent->new->get("https://encrypted.google.com/")->dump'500
Can't connect to encrypted.google.com:443 (Crypt-SSLeay can't verify
hostnames)
...

Would it be possible for LWP to set the HTTPS_CA_FILE environment
variable for Crypt::SSLeay? Then as long as Mozilla::CA is installed,
either SSL backend module would work without the user having to tweak
settings.

$ perl -MLWP::UserAgent -MMozilla::CA -E
'$ENV{HTTPS_CA_FILE}=Mozilla::CA::SSL_ca_file();
LWP::UserAgent->new->get("https://encrypted.google.com/")->dump'
HTTP/1.1 200 OK
...

Net::HTTPS will already set up $ENV{HTTPS_CA_FILE} based on Mozilla::CA's file.  The issue is 
that Crypt::SSLeay don't implement what corresponds to the SSL_verifycn_scheme option for 
IO::Socket::SSL and this option is implied by the 'verify_hostname' option.

If you disable 'verify_hostname' and set SSL_verify_mode => 1 then Net::SSL will verify that the 
certificate is legal, but only by setting various Client-* headers in the response.

On Sat Mar 12 10:23:18 2011, GAAS wrote:
> Net::HTTPS will already set up $ENV{HTTPS_CA_FILE} based on
> Mozilla::CA's file.  The issue is
> that Crypt::SSLeay don't implement what corresponds to the
> SSL_verifycn_scheme option for
> IO::Socket::SSL and this option is implied by the 'verify_hostname'
> option.
> 
> If you disable 'verify_hostname' and set SSL_verify_mode => 1 then
> Net::SSL will verify that the
> certificate is legal, but only by setting various Client-* headers in
> the response.

As many, many modules have libwww-perl as a dependency, I was hoping
this could be handled at the highest common level, instead of having
each dependent module author trying to solve this themselves. Maybe make
a note that this is on the todo wishlist, and some japh might submit a
patch :) Until that happens, how about adding a method to test if the
user needs to disable verify_hostname?

migrated queues: libwww-perl -> LWP-Protocol-https

# creating cert for direct.ssl.access
# creating cert for direct.ssl.access
# creating cert for foo
# creating cert for foo

#   Failed test 'proxy https://foo/bar -> C.9.Tauth@foo'
#   at t/https_proxy.t line 182.
#          got: '6.2.Tauth@foo'
#     expected: 'C.9.Tauth@foo'
# HTTP/1.1 200 ok
# Connection: close
# Content-Length: 85
# Content-Type: text/plain
# Client-Date: Fri, 21 Apr 2017 12:17:47 GMT
# Client-Peer: 127.0.0.1:58862
# Client-Response-Num: 1
# 
# ID: 6.2.Tauth@foo
# ---------
# GET /bar HTTP/
# Host: foo
# User-Agent: libwww-perl/6.26
# creating cert for bar
# creating cert for bar

#   Failed test 'proxy https://bar/bar -> F.3.Tauth@bar'
#   at t/https_proxy.t line 182.
#          got: '8.2.Tauth@bar'
#     expected: 'F.3.Tauth@bar'
# HTTP/1.1 200 ok
# Connection: close
# Content-Length: 85
# Content-Type: text/plain
# Client-Date: Fri, 21 Apr 2017 12:17:47 GMT
# Client-Peer: 127.0.0.1:58862
# Client-Response-Num: 1
# 
# ID: 8.2.Tauth@bar
# ---------
# GET /bar HTTP/
# Host: bar
# User-Agent: libwww-perl/6.26
# creating cert for foo

#   Failed test 'proxy https://foo/tor -> C.10.Tauth@foo'
#   at t/https_proxy.t line 182.
#          got: '9.2.Tauth@foo'
#     expected: 'C.10.Tauth@foo'
# HTTP/1.1 200 ok
# Connection: close
# Content-Length: 85
# Content-Type: text/plain
# Client-Date: Fri, 21 Apr 2017 12:17:47 GMT
# Client-Peer: 127.0.0.1:58862
# Client-Response-Num: 1
# 
# ID: 9.2.Tauth@foo
# ---------
# GET /tor HTTP/
# Host: foo
# User-Agent: libwww-perl/6.26
# creating cert for bar

#   Failed test 'proxy https://bar/tor -> F.4.Tauth@bar'
#   at t/https_proxy.t line 182.
#          got: '10.2.Tauth@bar'
#     expected: 'F.4.Tauth@bar'
# HTTP/1.1 200 ok
# Connection: close
# Content-Length: 86
# Content-Type: text/plain
# Client-Date: Fri, 21 Apr 2017 12:17:47 GMT
# Client-Peer: 127.0.0.1:58862
# Client-Response-Num: 1
# 
# ID: 10.2.Tauth@bar
# ---------
# GET /tor HTTP/
# Host: bar
# User-Agent: libwww-perl/6.26
# creating cert for foo
# creating cert for foo
# creating cert for bar
# creating cert for bar
# Looks like you failed 4 tests of 56.
t/https_proxy.t .. 
Dubious, test returned 4 (wstat 1024, 0x400)
Failed 4/56 subtests 

Checking if you have IO::Socket::SSL 1.54 ... Yes (2.046)
Checking if you have Mozilla::CA 20110101 ... Yes (20130114)
Checking if you have Net::HTTPS 6 ... Yes (6.09)
Checking if you have Test::More 0 ... Yes (1.302075)
Checking if you have LWP::UserAgent 6.06 ... Yes (6.26)
Checking if you have Test::RequiresInternet 0 ... Yes (0.05)

hello ,

i would like to use youtube-viewer on debian squeeze. it comes only with 
perl -v 5.10 so i updated systemwide via perlbrew

the program gives after compiling error
[501 Protocol scheme 'https' is not supported (LWP::Protocol::https not 
installed)]

LWP::Protocol::https is not available on squeeze


so i do

cpan LWP::Protocol::https


but this does not work out with the perlbrew version


#   Failed test at t/apache.t line 25.
# Looks like you failed 3 tests of 5.
t/apache.t ....... Dubious, test returned 3 (wstat 768, 0x300)
Failed 3/5 subtests
t/https_proxy.t .. Can't locate IO/Socket/SSL.pm in @INC (you may need 
to install the IO::Socket::SSL module)) at 
/home/ricci/perl5/perlbrew/perls/perl-5.20.1/lib/site_perl/5.20.1/Net/HTTPS.pm 
line 27.
Can't locate Net/SSL.pm in @INC (you may need to install the Net::SSL 
module) (@INC contains: 
/home/ricci/.cpan/build/LWP-Protocol-https-6.06-nAuSue/blib/lib 
/home/ricci/.cpan/build/LWP-Protocol-https-6.06-nAuSue/blib/arch 
/home/ricci/perl5/perlbrew/perls/perl-5.20.1/lib/site_perl/5.20.1/x86_64-linux 
/home/ricci/perl5/perlbrew/perls/perl-5.20.1/lib/site_perl/5.20.1 
/home/ricci/perl5/perlbrew/perls/perl-5.20.1/lib/5.20.1/x86_64-linux 
/home/ricci/perl5/perlbrew/perls/perl-5.20.1/lib/5.20.1 .) at 
/home/ricci/perl5/perlbrew/perls/perl-5.20.1/lib/site_perl/5.20.1/Net/HTTPS.pm 
line 31.
Compilation failed in require at 
/home/ricci/.cpan/build/LWP-Protocol-https-6.06-nAuSue/blib/lib/LWP/Protocol/https.pm 
line 8.
Compilation failed in require at t/https_proxy.t line 14.
BEGIN failed--compilation aborted at t/https_proxy.t line 14.
t/https_proxy.t .. Dubious, test returned 2 (wstat 512, 0x200)
No subtests run

Test Summary Report
-------------------
t/apache.t     (Wstat: 768 Tests: 5 Failed: 3)
   Failed tests:  1, 3-4
   Non-zero exit status: 3
t/https_proxy.t (Wstat: 512 Tests: 0 Failed: 0)
   Non-zero exit status: 2
   Parse errors: No plan found in TAP output
Files=2, Tests=5,  0 wallclock secs ( 0.04 usr  0.00 sys +  0.16 cusr 
0.00 csys =  0.20 CPU)
Result: FAIL
Failed 2/2 test programs. 3/5 subtests failed.
make: *** [test_dynamic] Fehler 2
   MSCHILLI/LWP-Protocol-https-6.06.tar.gz
one dependency not OK (IO::Socket::SSL); additionally test harness failed
   /usr/bin/make test -- NOT OK
//hint// to see the cpan-testers results for installing this module, try:
   reports MSCHILLI/LWP-Protocol-https-6.06.tar.gz




what i can do ? reinstall and use another method for updating perl? how 
can i overcome and install LWP-Protocol-https on Debian Squeeze?


Thanks - Danke - Grazie - Multumesq

You have problem installing IO::Socket::SSL. Check that you have libssl-dev package installed and try installing IO::Socket::SSL. If you still have problems, report it to IO::Socket::SSL bug tracker.

-- 
Alexandr Ciornii, http://chorny.net

adding $ua->env_proxy; to test fixes test failures on systems with an https proxy.

Hello there,

The reason why it happens (subject) is because it calls read/sysread millions of
times without waiting for read event. It fails with EAGAIN. I was
looking at the code and here is what i saw:

== lib / LWP / Protocol / https.pm ==
our @ISA = qw(Net::HTTPS LWP::Protocol::http::SocketMethods);
== lib / LWP / Protocol / https.pm ==

The parents order. Because Net::HTTPS goes first, it handles the sysread call.
That means sysread/can_read/select/sysread sequence from SocketMethods
never happens.
Looks it easy to fix, but it is not. You can't just change the order.
In this case sysread would not reach IO::Socket::SSL.

What i could do and it actually worked for me is copy/paste
sysread/can_read from SocketMethods and call IO::Socket::SSL::sysread
at the end. I guess there should be better way.

Thank you!

apache.org apparently is refusing connection based on useragent, so the test fails. i swapped 
apache.org with bankofamerica.com and it worked.  it might be a good idea to cycle through a 
randomized list of sites, and pass the test on the first successful site.

also, maybe this should be added as the first test:
ok($ua->is_protocol_supported('https'));

Seems unlikely that apache.org is denying access based on that.  Must be some other reason.  

i think this is an ipv6 problem related to:

http://stackoverflow.com/questions/11463748/perl-iosocketssl-connect-network-is-
unreachable

i was [finally] able to re-produce in CentOS6 x64, even with (i think) ipv6 turned off in the 
kernel, the app is trying to leverage the ipv6 nameserver response (for some reason it seems 
like RHEL wants to load up the ipv6 mod, but leave it 'disabled', which might be screwing up 
other code when they get ipv6 records back from NS and then repsond back with a network 
failure)

i tested against apache and google.com, same thing, added the 'inet4' to a fork of t/apache.t 
and it seems to work again.

this doesn't seem to happen on debian or ubuntu.. (fwiw), so i'm guessing it's a RHEL 
derivative thing.

i dunno that it's "safe" to have these sorts of network tests w/o explicit v4 or v6 
assignments... even though it's correct in saying something's wrong, wget and other apps 
seem to work OK, so maybe this is something that needs to be solved further down in the 
stack...(?)

probably a RHEL / IO::Socket::SSL bug (or similar), but for now, would it be safe to implicitly 
put inet4 in the test script?

something like:

use IO::Socket::SSL 'inet4';

more data:

after drilling down a bit more, i think it's a system call issue with centos and io-socket-inet6..

still something to be aware of with the tests (imo).

confirmed, bug is in io-socket-inet6 < 2.56 or so. seems to be fixed by 2.69, problem is the 
author of inet6 has some test bugs that need resolving. a straight install works and appears to 
solve the problem. i checked on ubuntu and that version of INET6.pm was > than 2.55, but that 
machine also has full ipv6 routing too...

again, something to be aware of when writing network tests...

On Thu Dec 27 07:08:40 2012, SAXJAZMAN wrote:
> confirmed, bug is in io-socket-inet6 < 2.56 or so. seems to be fixed
> by 2.69, problem is the
> author of inet6 has some test bugs that need resolving. a straight
> install works and appears to
> solve the problem. i checked on ubuntu and that version of INET6.pm
> was > than 2.55, but that
> machine also has full ipv6 routing too...
> 
> again, something to be aware of when writing network tests...

I ran into this issue trying to install Crypt::SSLeay on Mac OS X 10.6 with perl 5.10.  Crypt::SSLeay was suggesting that libssl-dev was missing but after some digging and finding this I updated IO::Socket::INET6 and Crypt::SSLeay along with LWP::Protocol::https installed properly.

On Sun Mar 02 14:10:26 2014, [email protected] wrote:

> I updated
> IO::Socket::INET6 and Crypt::SSLeay along with LWP::Protocol::https
> installed properly.

note that it was updated from version 2.56 to 2.72

On Sun Mar 02 14:25:31 2014, [email protected] wrote:
> On Sun Mar 02 14:10:26 2014, [email protected] wrote:
> 
> > I updated
> > IO::Socket::INET6 and Crypt::SSLeay along with LWP::Protocol::https
> > installed properly.
> 
> note that it was updated from version 2.56 to 2.72

I just tried using 2.57 and it did not allow LWP::Protocol::https to install but 2.58 did.

On Mon Mar 03 23:19:03 2014, [email protected] wrote:

> I just tried using 2.57 and it did not allow LWP::Protocol::https to
> install but 2.58 did.

Reported this as an issue with IO::Socket::INET6 here:
https://rt.cpan.org/Public/Bug/Display.html?id=93503

The next release should make things happy

Please add a test to this distribution that does a diag() of things like: path to openssl, output of 'openssl version', and the installed version of all network-related modules we can think of. This will greatly assist with narrowing down future failures.

I am using LWP with https protocol.  The message "Peer certificate not
verified" appears for me even with the patch from 2003 below.  However, with
a little tweak, the intent of the original bug fix can be extended to cover
Net::SSLeay ... works for me anyway.  With Net::SSLeay configured to do peer
verification and a successful verification the message is turned off
analogous to Crypt::SSLeay.

The original code in LWP/Protocol/https.pm is:
if(! eval { $sock->get_peer_verify }) {
  $res->header("Client-SSL-Warning" => "Peer certificate not verified");
}
Revised code:
if ((! eval { $sock->get_peer_verify }) && (! eval
{Net::SSLeay::get_verify_mode($sock)})) {
  $res->header("Client-SSL-Warning" => "Peer certificate not verified");
}

Original fix:
Re: PATCH: Peer certificate not verified for https Crypt::SSLeay
Gisle Aas
Wed, 15 Oct 2003 03:37:04 -0700

Another year old patch eventually applied.
Regards,
Gisle

Joshua Chamas <[EMAIL PROTECTED]> writes:
> Hey,
>
> Here is a patch against libwww-perl-5.64 that turns off the
> "Client-SSL-Warning" => "Peer certificate not verified"
> when Crypt::SSLeay has been configured to do peer certificate
> verification.  By wrapping the call in an eval {}, this patch
> should also be compatible with other SSL implementations that
> do not support this sock->get_peer_verify API.
>
> [EMAIL PROTECTED] libwww-perl-5.64]# diff -u lib/LWP/Protocol/https.pm.old

> lib/LWP/Protocol/https.pm
> --- lib/LWP/Protocol/https.pm.old     Fri Nov 16 18:10:28 2001
> +++ lib/LWP/Protocol/https.pm Mon Mar 18 12:38:37 2002
> @@ -34,7 +34,9 @@
>       $res->header("Client-SSL-Cert-Subject" => $cert->subject_name);
>       $res->header("Client-SSL-Cert-Issuer" => $cert->issuer_name);
>      }
> -    $res->header("Client-SSL-Warning" => "Peer certificate not
verified");
> +    if(! eval { $sock->get_peer_verify }) {
> +     $res->header("Client-SSL-Warning" => "Peer certificate not
verified");
> +    }
>  }
>
> Thanks,
>
> Josh

One thing I notices is there is a LWP/Protocol/https10.pm that is also
installed on my system and it does not have this conditional in it, but
perhaps it should.

Thanks,

Steve...

-- 
Steve Kneizys
Senior Business Process Engineer
Ferrilli Information Group
Voice: (610) 256-1396
web: http://www.figsolutions.com/

For Emergency Service (888)864-3282

I spoke too soon ... turns out my additional code does not work!  But the
problem does seem to exist, whether I pre-load IO::Socket::SSL (and I verify
it is being used),  then call IO::Socket::SSL to set the ctx_defaults to
verify the peer,  LWP::UserAgent  ends up giving me the message "Peer
certificate not verified" even when it has been.  I'll just ignore the
warning in my code :-)

Thanks,

Steve...
Original message:

>
> I am using LWP with https protocol.  The message "Peer certificate not
> verified" appears for me even with the patch from 2003 below.  However,
> with
> a little tweak, the intent of the original bug fix can be extended to cover
> Net::SSLeay ... works for me anyway.  With Net::SSLeay configured to do
> peer
> verification and a successful verification the message is turned off
> analogous to Crypt::SSLeay.
>
> The original code in LWP/Protocol/https.pm is:
> if(! eval { $sock->get_peer_verify }) {
>  $res->header("Client-SSL-Warning" => "Peer certificate not verified");
> }
> Revised code:
> if ((! eval { $sock->get_peer_verify }) && (! eval
> {Net::SSLeay::get_verify_mode($sock)})) {
>  $res->header("Client-SSL-Warning" => "Peer certificate not verified");
> }
>
> Original fix:
> Re: PATCH: Peer certificate not verified for https Crypt::SSLeay
> Gisle Aas
> Wed, 15 Oct 2003 03:37:04 -0700
>
> Another year old patch eventually applied.
> Regards,
> Gisle
>
> Joshua Chamas <[EMAIL PROTECTED]> writes:
> > Hey,
> >
> > Here is a patch against libwww-perl-5.64 that turns off the
> > "Client-SSL-Warning" => "Peer certificate not verified"
> > when Crypt::SSLeay has been configured to do peer certificate
> > verification.  By wrapping the call in an eval {}, this patch
> > should also be compatible with other SSL implementations that
> > do not support this sock->get_peer_verify API.
> >
> > [EMAIL PROTECTED] libwww-perl-5.64]# diff -u
> lib/LWP/Protocol/https.pm.old
>
> > lib/LWP/Protocol/https.pm
> > --- lib/LWP/Protocol/https.pm.old     Fri Nov 16 18:10:28 2001
> > +++ lib/LWP/Protocol/https.pm Mon Mar 18 12:38:37 2002
> > @@ -34,7 +34,9 @@
> >       $res->header("Client-SSL-Cert-Subject" => $cert->subject_name);
> >       $res->header("Client-SSL-Cert-Issuer" => $cert->issuer_name);
> >      }
> > -    $res->header("Client-SSL-Warning" => "Peer certificate not
> verified");
> > +    if(! eval { $sock->get_peer_verify }) {
> > +     $res->header("Client-SSL-Warning" => "Peer certificate not
> verified");
> > +    }
> >  }
> >
> > Thanks,
> >
> > Josh
>
> One thing I notices is there is a LWP/Protocol/https10.pm that is also
> installed on my system and it does not have this conditional in it, but
> perhaps it should.
>
> Thanks,
>
> Steve...
>
> --
> Steve Kneizys
> Senior Business Process Engineer
> Ferrilli Information Group
> Voice: (610) 256-1396
> web: http://www.figsolutions.com/
>
> For Emergency Service (888)864-3282
>
>

This Debian bug report seems relevant.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503440

http://bugs.debian.org/503440 is marked as forwarded upstream to

   https://rt.cpan.org/Public/Bug/Display.html?id=61340

But i don't think these are the same issue at all.

the CPAN bug has nothing to do with using a proxy.

the debian bug is about LWP failing to make proper use of the HTTP
proxy, as noted here:


http://www.annocpan.org/~GAAS/libwww-perl-5.834/lib/LWP/UserAgent.pm#note_751

I think the appropriate CPAN bug to reference is actually:

  https://rt.cpan.org/Public/Bug/Display.html?id=1894

	--dkg

migrated queues: libwww-perl -> LWP-Protocol-https

Hello,

If you want to disable ssl cert verification, you need to use
SSL_VERIFY_NONE, which resolves to 0. LWP::Protocol::https transforms this
value to 1:

$ssl_opts{SSL_verify_mode} ||= 1;
Patch:

--- https_old.pm        2016-01-28 16:51:38.970331004 +0000
+++ https.pm    2016-01-28 16:42:22.410331004 +0000
@@ -17,7 +17,8 @@
     my $self = shift;
     my %ssl_opts = %{$self->{ua}{ssl_opts} || {}};
     if (delete $ssl_opts{verify_hostname}) {
-       $ssl_opts{SSL_verify_mode} ||= 1;
+       $ssl_opts{SSL_verify_mode} = defined $ssl_opts{SSL_verify_mode} ?
$ssl_opts{SSL_verify_mode} : 1;
+
        $ssl_opts{SSL_verifycn_scheme} = 'www';
     }
     else {
-- 
Errietta Kostala
<[email protected]>

Versions:
LWP::Protocol::https 6.06
This is perl 5, version 22, subversion 1 (v5.22.1) built for
x86_64-linux-gnu-thread-multi


On Thu, Jan 28, 2016 at 4:53 PM Bugs in LWP-Protocol-https via RT <
[email protected]> wrote:

>
> Greetings,
>
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
>         "LWP::Protocol::https discards 0 value for SSL_VERIFY_mode",
> a summary of which appears below.
>
> There is no need to reply to this message right now.  Your ticket has been
> assigned an ID of [rt.cpan.org #111517].  Your ticket is accessible
> on the web at:
>
>     https://rt.cpan.org/Ticket/Display.html?id=111517
>
> Please include the string:
>
>          [rt.cpan.org #111517]
>
> in the subject line of all future correspondence about this issue. To do
> so,
> you may reply to this message.
>
>                         Thank you,
>                         [email protected]
>
> -------------------------------------------------------------------------
> Hello,
>
> If you want to disable ssl cert verification, you need to use
> SSL_VERIFY_NONE, which resolves to 0. LWP::Protocol::https transforms this
> value to 1:
>
> $ssl_opts{SSL_verify_mode} ||= 1;
> Patch:
>
> --- https_old.pm        2016-01-28 16:51:38.970331004 +0000
> +++ https.pm    2016-01-28 16:42:22.410331004 +0000
> @@ -17,7 +17,8 @@
>      my $self = shift;
>      my %ssl_opts = %{$self->{ua}{ssl_opts} || {}};
>      if (delete $ssl_opts{verify_hostname}) {
> -       $ssl_opts{SSL_verify_mode} ||= 1;
> +       $ssl_opts{SSL_verify_mode} = defined $ssl_opts{SSL_verify_mode} ?
> $ssl_opts{SSL_verify_mode} : 1;
> +
>         $ssl_opts{SSL_verifycn_scheme} = 'www';
>      }
>      else {
> --
> Errietta Kostala
> <[email protected]>
>
-- 
Errietta Kostala
<[email protected]>

I can confirm this bug. In general it is of course not a good thing to turn off SSL verification but there are legitimate cases for this. This bug in combination with changed behavior in IO::Socket::SSL makes it impossible to turn off SSL verification (it used to be possible to pass a non-numerical value to IO::Socket::SSL and that would do the trick).

Fixing this would be highly appreciated!

/Sune

--
Sune Karlsson
Professor of Statistics
Handelshögskolan/�rebro University School of Business
�rebro University, SE-70182 �rebro, Sweden
Phone +46 19 301257
http://www.oru.se/hh/sune_karlsson
http://econpapers.repec.org/RAS/pka1.htm

Please also change

$ssl_opts{SSL_verifycn_scheme} = 'www';
to
$ssl_opts{SSL_verifycn_scheme} ||= 'www';

That way we can pass along our own verification scheme.
 For example if we want to verify a portion of the hostname or something like:
 LWP::UserAgent->new( ssl_opts => {
   SSL_verifycn_scheme => {
    callback => sub {
     if ($_[1] =~ m/^$_[0]:.*/) {
         return 1;
     }
      return 0;
     }
  }});

Also in the same method, shouldn't the return be

return ($self->SUPER::_extra_sock_opts, %ssl_opts);
not
return (%ssl_opts, $self->SUPER::_extra_sock_opts);

Otherwise your base class would be overriding your subclasses options.

On Wed Jul 06 19:24:15 2016, [email protected] wrote:
> Please also change
> 
> $ssl_opts{SSL_verifycn_scheme} = 'www';
> to
> $ssl_opts{SSL_verifycn_scheme} ||= 'www';
> 
> That way we can pass along our own verification scheme.
>  For example if we want to verify a portion of the hostname or
> something like:
>  LWP::UserAgent->new( ssl_opts => {
>    SSL_verifycn_scheme => {
>     callback => sub {
>      if ($_[1] =~ m/^$_[0]:.*/) {
>          return 1;
>      }
>       return 0;
>      }
>   }});

PS C:\> cpan install LWP::Protocol::https
Loading internal logger. Log::Log4perl recommended for better logging
CPAN: CPAN::SQLite loaded ok (v0.217)
Database was generated on Sun, 22 Nov 2020 20:05:47 GMT
Running install for module 'LWP::Protocol::https'
CPAN: Digest::SHA loaded ok (v6.02)
CPAN: Compress::Zlib loaded ok (v2.09)
Checksum for C:\berrybrew\5.30.1_64\cpan\sources\authors\id\O\OA\OALDERS\LWP-Protocol-https-6.09.tar.gz ok
CPAN: Archive::Tar loaded ok (v2.32)
CPAN: YAML::XS loaded ok (v0.80)
CPAN: CPAN::Meta::Requirements loaded ok (v2.140)
CPAN: Parse::CPAN::Meta loaded ok (v2.150010)
CPAN: CPAN::Meta loaded ok (v2.150010)
CPAN: Module::CoreList loaded ok (v5.20191120)
Configuring O/OA/OALDERS/LWP-Protocol-https-6.09.tar.gz with Makefile.PL
Checking if your kit is complete...
Looks good
Generating a gmake-style Makefile
Writing Makefile for LWP::Protocol::https
Writing MYMETA.yml and MYMETA.json
  OALDERS/LWP-Protocol-https-6.09.tar.gz
  C:\berrybrew\5.30.1_64\perl\bin\perl.exe Makefile.PL -- OK
Running make for O/OA/OALDERS/LWP-Protocol-https-6.09.tar.gz
cp lib/LWP/Protocol/https.pm blib\lib\LWP\Protocol\https.pm
  OALDERS/LWP-Protocol-https-6.09.tar.gz
  C:\berrybrew\5.30.1_64\c\bin\gmake.exe -- OK
Running make test for OALDERS/LWP-Protocol-https-6.09.tar.gz
"C:\berrybrew\5.30.1_64\perl\bin\perl.exe" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib\lib', 'blib\arch')" t/*.t
t/00-report-prereqs.t .. #
# Versions for all modules listed in MYMETA.json (including optional ones):
#
# === Configure Requires ===
#
#     Module              Want Have
#     ------------------- ---- ----
#     ExtUtils::MakeMaker  any 7.38
#
# === Configure Suggests ===
#
#     Module      Want Have
#     -------- ------- ----
#     JSON::PP 2.27300 4.04
#
# === Build Requires ===
#
#     Module              Want Have
#     ------------------- ---- ----
#     ExtUtils::MakeMaker  any 7.38
#
# === Test Requires ===
#
#     Module                 Want     Have
#     ---------------------- ---- --------
#     ExtUtils::MakeMaker     any     7.38
#     File::Spec              any     3.78
#     File::Temp              any   0.2309
#     IO::Select              any     1.40
#     IO::Socket::INET        any     1.40
#     IO::Socket::SSL        1.54    2.066
#     IO::Socket::SSL::Utils  any    2.014
#     LWP::UserAgent         6.06     6.42
#     Socket                  any    2.029
#     Test::More              any 1.302169
#     Test::RequiresInternet  any     0.05
#     warnings                any     1.44
#
# === Test Recommends ===
#
#     Module         Want     Have
#     ---------- -------- --------
#     CPAN::Meta 2.120900 2.150010
#
# === Runtime Requires ===
#
#     Module                  Want     Have
#     ------------------- -------- --------
#     IO::Socket::SSL         1.54    2.066
#     LWP::Protocol::http      any     6.42
#     LWP::UserAgent          6.06     6.42
#     Mozilla::CA         20180117 20180117
#     Net::HTTPS                 6     6.19
#     base                     any     2.27
#     strict                   any     1.11
#
t/00-report-prereqs.t .. ok
t/apache.t ............. ok
t/https_proxy.t ........ 1/56 # creating cert for direct.ssl.access
# creating cert for direct.ssl.access
# creating cert for foo
unexpected response: 500 SSL upgrade failed: SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
Content-Type: text/plain
Client-Date: Sun, 22 Nov 2020 20:14:20 GMT
Client-Warning: Internal response

SSL upgrade failed: SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed at C:/berrybrew/5.30.1_64/perl/vendor/lib/LWP/Protocol/http.pm line 209.
# Looks like your test exited with 9 just after 36.
t/https_proxy.t ........ Dubious, test returned 9 (wstat 2304, 0x900)
Failed 20/56 subtests
t/method_in_san.t ...... ok

Test Summary Report
-------------------
t/https_proxy.t      (Wstat: 2304 Tests: 36 Failed: 0)
  Non-zero exit status: 9
  Parse errors: Bad plan.  You planned 56 tests but ran 36.
Files=4, Tests=56,  6 wallclock secs ( 0.03 usr +  0.03 sys =  0.06 CPU)
Result: FAIL
Failed 1/4 test programs. 0/56 subtests failed.
gmake: *** [Makefile:890: test_dynamic] Error 255
  OALDERS/LWP-Protocol-https-6.09.tar.gz
  C:\berrybrew\5.30.1_64\c\bin\gmake.exe test -- NOT OK
//hint// to see the cpan-testers results for installing this module, try:
  reports OALDERS/LWP-Protocol-https-6.09.tar.gz
Stopping: 'install' failed for 'LWP::Protocol::https'.

If there is no network access, or the firewall is blocking access, I should still be able to install LWP::Protocol::https without having to force it.

Perhaps apache.t should use a short timeout and skip the test.

But only in first request, second request is ok. Does not depend on presence of IO::Socket::INET6.
Strawberry perl 5.16.0
Mozilla::CA 20120309
IO::Socket::INET6 2.71
IO::Socket::SSL 1.962

with diagnostic patch https://github.com/libwww-perl/lwp-protocol-https/pull/9

not ok 2
#   Failed test at t/apache.t line 22.
#                   ''
#     doesn't match '(?^:Apache Software Foundation)'
not ok 3 - no X-Died header
#   Failed test 'no X-Died header'
#   at t/apache.t line 24.
#          got: 'read failed: No such file or directory at C:/strawberry160/perl
/site/lib/LWP/Protocol/http.pm line 414.'
#     expected: undef

-- 
Alexandr Ciornii, http://chorny.net

On Wed Dec 25 10:13:57 2013, CHORNY wrote:
> not ok 2
> #   Failed test at t/apache.t line 22.
> #                   ''
> #     doesn't match '(?^:Apache Software Foundation)'
> not ok 3 - no X-Died header
> #   Failed test 'no X-Died header'
> #   at t/apache.t line 24.
> #          got: 'read failed: No such file or directory at

I used to see this error too, but it is now gone.  I suspect it was fixed by updating Net::HTTP with the fix for RT#104122.

You may want to update to Net-HTTP-6.09  and check if you can still reproduce this issue.

Cheers,
-Jan

On Wed Jun 10 14:40:59 2015, JDB wrote:
> On Wed Dec 25 10:13:57 2013, CHORNY wrote:
> > not ok 2
> > #   Failed test at t/apache.t line 22.
> > #                   ''
> > #     doesn't match '(?^:Apache Software Foundation)'
> > not ok 3 - no X-Died header
> > #   Failed test 'no X-Died header'
> > #   at t/apache.t line 24.
> > #          got: 'read failed: No such file or directory at
> 
> I used to see this error too, but it is now gone.  I suspect it was
> fixed by updating Net::HTTP with the fix for RT#104122.
> 
> You may want to update to Net-HTTP-6.09  and check if you can still
> reproduce this issue.

Checked, same error.


-- 
Alexandr Ciornii, http://chorny.net

1..56
ok 1 - noproxy http://127.0.0.1:2809/foo -> A.1@nossl
ok 2 - URL in request -> /foo
ok 3 - noproxy http://127.0.0.1:2809/bar -> A.2@nossl
ok 4 - URL in request -> /bar
ok 5 - noproxy http://127.0.0.1:2810/foo -> B.1@nossl
ok 6 - URL in request -> /foo
ok 7 - noproxy http://127.0.0.1:2810/bar -> B.2@nossl
ok 8 - URL in request -> /bar
ok 9 - noproxy http://127.0.0.1:2809/tor -> A.3@nossl
ok 10 - URL in request -> /tor
ok 11 - noproxy http://127.0.0.1:2810/tor -> B.3@nossl
ok 12 - URL in request -> /tor
ok 13 - proxy http://foo/foo -> C.1.auth@nossl
ok 14 - URL in request -> http://foo/foo
ok 15 - proxy http://foo/bar -> C.2.auth@nossl
ok 16 - URL in request -> http://foo/bar
ok 17 - proxy http://bar/foo -> C.3.auth@nossl
ok 18 - URL in request -> http://bar/foo
ok 19 - proxy http://bar/bar -> C.4.auth@nossl
ok 20 - URL in request -> http://bar/bar
ok 21 - proxy http://foo/tor -> C.5.auth@nossl
ok 22 - URL in request -> http://foo/tor
ok 23 - proxy http://bar/tor -> C.6.auth@nossl
ok 24 - URL in request -> http://bar/tor
# creating cert for direct.ssl.access
ok 25 - noproxy https://127.0.0.1:2809/foo -> [email protected]
ok 26 - URL in request -> /foo
ok 27 - noproxy https://127.0.0.1:2809/bar -> [email protected]
ok 28 - URL in request -> /bar
# creating cert for direct.ssl.access
ok 29 - noproxy https://127.0.0.1:2810/foo -> [email protected]
ok 30 - URL in request -> /foo
ok 31 - noproxy https://127.0.0.1:2810/bar -> [email protected]
ok 32 - URL in request -> /bar
ok 33 - noproxy https://127.0.0.1:2809/tor -> [email protected]
ok 34 - URL in request -> /tor
ok 35 - noproxy https://127.0.0.1:2810/tor -> [email protected]
ok 36 - URL in request -> /tor
not ok 37 - proxy https://foo/foo -> C.8.Tauth@foo
#   Failed test 'proxy https://foo/foo -> C.8.Tauth@foo'
#   at t/https_proxy.t line 182.
#          got: 'C.7.auth@nossl'
#     expected: 'C.8.Tauth@foo'
# HTTP/1.1 200 ok
# Connection: keep-alive
# Content-Length: 181
# Content-Type: text/plain
# Client-Date: Wed, 25 Dec 2013 14:20:14 GMT
# Client-Peer: 127.0.0.1:2809
# Client-Response-Num: 7
# 
# ID: 3.7.auth@nossl
# ---------
# GET https://foo/foo HTTP/1.1

# TE: deflate,gzip;q=0.3

# Connection: TE

# Host: foo

# Proxy-Authorization: Basic Zm9vOmJhcg==

# User-Agent: libwww-perl/6.05

not ok 38 - URL in request -> /foo
#   Failed test 'URL in request -> /foo'
#   at t/https_proxy.t line 190.
#          got: 'https://foo/foo'
#     expected: '/foo'
not ok 39 - proxy https://foo/bar -> C.9.Tauth@foo
#   Failed test 'proxy https://foo/bar -> C.9.Tauth@foo'
#   at t/https_proxy.t line 182.
#          got: 'C.8.auth@nossl'
#     expected: 'C.9.Tauth@foo'
# HTTP/1.1 200 ok
# Connection: keep-alive
# Content-Length: 181
# Content-Type: text/plain
# Client-Date: Wed, 25 Dec 2013 14:20:14 GMT
# Client-Peer: 127.0.0.1:2809
# Client-Response-Num: 8
# 
# ID: 3.8.auth@nossl
# ---------
# GET https://foo/bar HTTP/1.1

# TE: deflate,gzip;q=0.3

# Connection: TE

# Host: foo

# Proxy-Authorization: Basic Zm9vOmJhcg==

# User-Agent: libwww-perl/6.05

not ok 40 - URL in request -> /bar
#   Failed test 'URL in request -> /bar'
#   at t/https_proxy.t line 190.
#          got: 'https://foo/bar'
#     expected: '/bar'
not ok 41 - proxy https://bar/foo -> F.2.Tauth@bar
#   Failed test 'proxy https://bar/foo -> F.2.Tauth@bar'
#   at t/https_proxy.t line 182.
#          got: 'C.9.auth@nossl'
#     expected: 'F.2.Tauth@bar'
# HTTP/1.1 200 ok
# Connection: keep-alive
# Content-Length: 181
# Content-Type: text/plain
# Client-Date: Wed, 25 Dec 2013 14:20:14 GMT
# Client-Peer: 127.0.0.1:2809
# Client-Response-Num: 9
# 
# ID: 3.9.auth@nossl
# ---------
# GET https://bar/foo HTTP/1.1

# TE: deflate,gzip;q=0.3

# Connection: TE

# Host: bar

# Proxy-Authorization: Basic Zm9vOmJhcg==

# User-Agent: libwww-perl/6.05

not ok 42 - URL in request -> /foo
#   Failed test 'URL in request -> /foo'
#   at t/https_proxy.t line 190.
#          got: 'https://bar/foo'
#     expected: '/foo'
not ok 43 - proxy https://bar/bar -> F.3.Tauth@bar
#   Failed test 'proxy https://bar/bar -> F.3.Tauth@bar'
#   at t/https_proxy.t line 182.
#          got: 'C.10.auth@nossl'
#     expected: 'F.3.Tauth@bar'
# HTTP/1.1 200 ok
# Connection: keep-alive
# Content-Length: 182
# Content-Type: text/plain
# Client-Date: Wed, 25 Dec 2013 14:20:15 GMT
# Client-Peer: 127.0.0.1:2809
# Client-Response-Num: 10
# 
# ID: 3.10.auth@nossl
# ---------
# GET https://bar/bar HTTP/1.1

# TE: deflate,gzip;q=0.3

# Connection: TE

# Host: bar

# Proxy-Authorization: Basic Zm9vOmJhcg==

# User-Agent: libwww-perl/6.05

not ok 44 - URL in request -> /bar
#   Failed test 'URL in request -> /bar'
#   at t/https_proxy.t line 190.
#          got: 'https://bar/bar'
#     expected: '/bar'
not ok 45 - proxy https://foo/tor -> C.10.Tauth@foo
#   Failed test 'proxy https://foo/tor -> C.10.Tauth@foo'
#   at t/https_proxy.t line 182.
#          got: 'C.11.auth@nossl'
#     expected: 'C.10.Tauth@foo'
# HTTP/1.1 200 ok
# Connection: keep-alive
# Content-Length: 182
# Content-Type: text/plain
# Client-Date: Wed, 25 Dec 2013 14:20:15 GMT
# Client-Peer: 127.0.0.1:2809
# Client-Response-Num: 11
# 
# ID: 3.11.auth@nossl
# ---------
# GET https://foo/tor HTTP/1.1

# TE: deflate,gzip;q=0.3

# Connection: TE

# Host: foo

# Proxy-Authorization: Basic Zm9vOmJhcg==

# User-Agent: libwww-perl/6.05

not ok 46 - URL in request -> /tor
#   Failed test 'URL in request -> /tor'
#   at t/https_proxy.t line 190.
#          got: 'https://foo/tor'
#     expected: '/tor'
not ok 47 - proxy https://bar/tor -> F.4.Tauth@bar
#   Failed test 'proxy https://bar/tor -> F.4.Tauth@bar'
#   at t/https_proxy.t line 182.
#          got: 'C.12.auth@nossl'
#     expected: 'F.4.Tauth@bar'
# HTTP/1.1 200 ok
# Connection: keep-alive
# Content-Length: 182
# Content-Type: text/plain
# Client-Date: Wed, 25 Dec 2013 14:20:15 GMT
# Client-Peer: 127.0.0.1:2809
# Client-Response-Num: 12
# 
# ID: 3.12.auth@nossl
# ---------
# GET https://bar/tor HTTP/1.1

# TE: deflate,gzip;q=0.3

# Connection: TE

# Host: bar

# Proxy-Authorization: Basic Zm9vOmJhcg==

# User-Agent: libwww-perl/6.05

not ok 48 - URL in request -> /tor
#   Failed test 'URL in request -> /tor'
#   at t/https_proxy.t line 190.
#          got: 'https://bar/tor'
#     expected: '/tor'
not ok 49 - proxy_nokeepalive https://foo/foo -> H.2.Tauth@foo
#   Failed test 'proxy_nokeepalive https://foo/foo -> H.2.Tauth@foo'
#   at t/https_proxy.t line 182.
#          got: 'H.1.auth@nossl'
#     expected: 'H.2.Tauth@foo'
# HTTP/1.1 200 ok
# Connection: keep-alive
# Content-Length: 188
# Content-Type: text/plain
# Client-Date: Wed, 25 Dec 2013 14:20:15 GMT
# Client-Peer: 127.0.0.1:2809
# Client-Response-Num: 1
# 
# ID: 6.1.auth@nossl
# ---------
# GET https://foo/foo HTTP/1.1

# TE: deflate,gzip;q=0.3

# Connection: TE, close

# Host: foo

# Proxy-Authorization: Basic Zm9vOmJhcg==

# User-Agent: libwww-perl/6.05

not ok 50 - URL in request -> /foo
#   Failed test 'URL in request -> /foo'
#   at t/https_proxy.t line 190.
#          got: 'https://foo/foo'
#     expected: '/foo'
not ok 51 - proxy_nokeepalive https://foo/bar -> I.2.Tauth@foo
#   Failed test 'proxy_nokeepalive https://foo/bar -> I.2.Tauth@foo'
#   at t/https_proxy.t line 182.
#          got: 'I.1.auth@nossl'
#     expected: 'I.2.Tauth@foo'
# HTTP/1.1 200 ok
# Connection: keep-alive
# Content-Length: 188
# Content-Type: text/plain
# Client-Date: Wed, 25 Dec 2013 14:20:15 GMT
# Client-Peer: 127.0.0.1:2809
# Client-Response-Num: 1
# 
# ID: 7.1.auth@nossl
# ---------
# GET https://foo/bar HTTP/1.1

# TE: deflate,gzip;q=0.3

# Connection: TE, close

# Host: foo

# Proxy-Authorization: Basic Zm9vOmJhcg==

# User-Agent: libwww-perl/6.05

not ok 52 - URL in request -> /bar
#   Failed test 'URL in request -> /bar'
#   at t/https_proxy.t line 190.
#          got: 'https://foo/bar'
#     expected: '/bar'
not ok 53 - proxy_nokeepalive https://bar/foo -> J.2.Tauth@bar
#   Failed test 'proxy_nokeepalive https://bar/foo -> J.2.Tauth@bar'
#   at t/https_proxy.t line 182.
#          got: 'J.1.auth@nossl'
#     expected: 'J.2.Tauth@bar'
# HTTP/1.1 200 ok
# Connection: keep-alive
# Content-Length: 188
# Content-Type: text/plain
# Client-Date: Wed, 25 Dec 2013 14:20:16 GMT
# Client-Peer: 127.0.0.1:2809
# Client-Response-Num: 1
# 
# ID: 8.1.auth@nossl
# ---------
# GET https://bar/foo HTTP/1.1

# TE: deflate,gzip;q=0.3

# Connection: TE, close

# Host: bar

# Proxy-Authorization: Basic Zm9vOmJhcg==

# User-Agent: libwww-perl/6.05

not ok 54 - URL in request -> /foo
#   Failed test 'URL in request -> /foo'
#   at t/https_proxy.t line 190.
#          got: 'https://bar/foo'
#     expected: '/foo'
not ok 55 - proxy_nokeepalive https://bar/bar -> K.2.Tauth@bar
#   Failed test 'proxy_nokeepalive https://bar/bar -> K.2.Tauth@bar'
#   at t/https_proxy.t line 182.
#          got: 'K.1.auth@nossl'
#     expected: 'K.2.Tauth@bar'
# HTTP/1.1 200 ok
# Connection: keep-alive
# Content-Length: 188
# Content-Type: text/plain
# Client-Date: Wed, 25 Dec 2013 14:20:16 GMT
# Client-Peer: 127.0.0.1:2809
# Client-Response-Num: 1
# 
# ID: 9.1.auth@nossl
# ---------
# GET https://bar/bar HTTP/1.1

# TE: deflate,gzip;q=0.3

# Connection: TE, close

# Host: bar

# Proxy-Authorization: Basic Zm9vOmJhcg==

# User-Agent: libwww-perl/6.05

not ok 56 - URL in request -> /bar
#   Failed test 'URL in request -> /bar'
#   at t/https_proxy.t line 190.
#          got: 'https://bar/bar'
#     expected: '/bar'
# Looks like you failed 20 tests of 56.

Reproduce:

On clean CentOS 5.x (which is supported till Y2017 btw):
install perl-Net-SSLeay OS package.
then

cpan -i LWP::Protocol::https

it will fail, with

t/apache....NOK 1                                                      
     
#   Failed test at t/apache.t line 14.
t/apache....NOK 2                                                      
     
#   Failed test at t/apache.t line 15.
#                   'you need at least Net::SSLeay version 1.33 for
getting subjectAltNames at
/usr/lib/perl5/site_perl/5.8.8/IO/Socket/SSL.pm line 1702
# '
#     doesn't match '(?-xism:Apache Software Foundation)'
# Looks like you failed 2 tests of 2.


because we have older Net::SSLeay version, and minimal version 1.33 is
not mentioned in META.yml

Forwarding from http://bugs.debian.org/507402
---

Forwarded from Ubuntu #198874 
(https://bugs.launchpad.net/ubuntu/+source/libwww-perl/+bug/198874):

The reporter states:
"See LWP::Protocol::https class, the _check_sock function:

we don't execute $sock->get_peer_verify before checking the cert's 
subject against $req->header("If-SSL-Cert-Subject").

$sock->get_peer_verify gets called only *after* we have pushed all of 
our request to the server (possibly containing critical data including 
passwords) -- that is BAAAAD. Basically, all of that renders SSL support 
in LWP::UserAgent not only meaningless, but also gives the user 
impression of security, which is not only bad, but almost a malicious 
thing to do.

More experimentation has shown that this only happens when doing "use 
IO::Socket::SSL". Otherwise, Crypt::SSLeay is used and that one shows 
the opposite behaviour: unverified server certs are NEVER accepted. I 
don't even know how to set the verification level und neither seems to 
be documented what exactly gets verified.... (server name at least?? How 
about redirects?....)

Please fix this and/or report it upstream because I consider it a major 
issue."

migrated queues: libwww-perl -> LWP-Protocol-https

Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian Perl Group <[email protected]>

If you wish to submit further information on this problem, please
send it to [email protected].

Please do not send mail to [email protected] unless you wish
to report a problem with the Bug-tracking system.

-- 
507402: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507402
Debian Bug Tracking System
Contact [email protected] with problems

 Can't connect to www.apache.org:443 (No route to host)
 LWP::Protocol::https::Socket: connect: No route to host at /Library/Perl/5.10.0/LWP/Protocol/http.pm line 51.

perl -V
Summary of my perl5 (revision 5 version 10 subversion 0) configuration:
  Platform:
    osname=darwin, osvers=10.0, archname=darwin-thread-multi-2level
    uname='darwin pizzly.apple.com 10.0 darwin kernel version 10.0.0: fri jul 31 22:46:25 pdt 2009; root:xnu-1456.1.25~1release_x86_64 x86_64 '
    config_args='-ds -e -Dprefix=/usr -Dccflags=-g  -pipe  -Dldflags= -Dman3ext=3pm -Duseithreads -Duseshrplib -Dinc_version_list=none -Dcc=gcc-4.2'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc-4.2', ccflags ='-arch x86_64 -g -pipe -fno-common -DPERL_DARWIN -fno-strict-aliasing -I/usr/local/include',
    optimize='-Os',
    cppflags='-g -pipe -fno-common -DPERL_DARWIN -fno-strict-aliasing -I/usr/local/include'
    ccversion='', gccversion='4.2.1 (Apple Inc. build 5646)', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='gcc-4.2 -mmacosx-version-min=10.6.3', ldflags ='-arch x86_64 -L/usr/local/lib'
    libpth=/usr/local/lib /usr/lib
    libs=-ldbm -ldl -lm -lutil -lc
    perllibs=-ldl -lm -lutil -lc
    libc=/usr/lib/libc.dylib, so=dylib, useshrplib=true, libperl=libperl.dylib
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', lddlflags='-arch x86_64 -bundle -undefined dynamic_lookup -L/usr/local/lib'


Characteristics of this binary (from libperl): 
  Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV
                        PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP USE_64_BIT_ALL
                        USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES
                        USE_PERLIO USE_REENTRANT_API
  Locally applied patches:
    /Library/Perl/Updates/<version> comes before system perl directories
    installprivlib and installarchlib points to the Updates directory
  Built under darwin
  Compiled at Jan 26 2010 17:48:53
  @INC:
    /Library/Perl/Updates/5.10.0/darwin-thread-multi-2level
    /Library/Perl/Updates/5.10.0
    /System/Library/Perl/5.10.0/darwin-thread-multi-2level
    /System/Library/Perl/5.10.0
    /Library/Perl/5.10.0/darwin-thread-multi-2level
    /Library/Perl/5.10.0
    /Network/Library/Perl/5.10.0/darwin-thread-multi-2level
    /Network/Library/Perl/5.10.0
    /Network/Library/Perl
    /System/Library/Perl/Extras/5.10.0/darwin-thread-multi-2level
    /System/Library/Perl/Extras/5.10.0

tests passes when prereq IO::Socket::SSL 1.54 not met
thus it gets installed with IO::Socket::SSL 1.38 (however it should not)

Test Summary Report
-------------------
t/apache.t           (Wstat: 512 Tests: 2 Failed: 2)
  Failed tests:  1-2
  Non-zero exit status: 2
t/https_proxy.t      (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
t/method_in_san.t    (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: Bad plan.  You planned 17 tests but ran 0.
Files=4, Tests=3,  1 wallclock secs ( 0.02 usr  0.01 sys +  0.50 cusr  0.12 csys =  0.65 CPU)
Result: FAIL
Failed 3/4 test programs. 2/3 subtests failed.
make: *** [test_dynamic] Error 22
  OALDERS/LWP-Protocol-https-6.10.tar.gz
2 dependencies missing (IO::Socket::SSL,IO::Socket::SSL::Utils); additionally test harness failed
  /usr/bin/make test -- NOT OK
//hint// to see the cpan-testers results for installing this module, try:
  reports OALDERS/LWP-Protocol-https-6.10.tar.gz

Hi,

We are using LWP 5.837, bundled with ActiveState 5.10.1008 on Windows 7 64 bit, but I just took a look at the libwww-perl repository on github and the most recent commit, 93c26dd32aea887331860e7afbc68d34e141ddab, has the same issue I think.

What I was trying to do was doing a POST request on a https url that requires basic authentication, deliberately giving it wrong credentials. Instead of returning an HTTP::response object with a 401 error, the HTTP::UserAgent->request call just hang and never returned. Tracking it down I found out that the actual call that was not returning was in Net::HTTP::Methods::my_read, calling $self->sysread.

Turns out that in our case $self->sysread resolves to Net::SSL::read, which I think should have been 
LWP::Protocol::http::SocketMethods::sysread instead.

In our case Net::HTTPS isa Net::SSL and Net::SSL implements a sysread, which gets found earlier than LWP::Protocol::https::SocketMethods' sysread due to the order in which perl looks for methods in superclasses.
The origin of this problem resides in LWP::Protocol::https.pm, in which I think this line:

@ISA = qw(Net::HTTPS LWP::Protocol::http::SocketMethods);

should be:

@ISA = qw(LWP::Protocol::http::SocketMethods Net::HTTPS);

At least in our case this change fixes the problem. The wrongly authenticated request now returns with a HTTP::response object having the 401 status and doesn't hang anymore.

Regards,
Tom Koelman

migrated queues: libwww-perl -> LWP-Protocol-https