You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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'));
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, dsteinbrunner@pobox.com 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, dsteinbrunner@pobox.com wrote:
> On Sun Mar 02 14:10:26 2014, dsteinbrunner@pobox.com 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, dsteinbrunner@pobox.com 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
The text was updated successfully, but these errors were encountered:
Migrated from rt.cpan.org#67001 (status was 'open')
Requestors:
From blue@thisisnotmyrealemail.com on 2011-03-27 16:24:59:
From gaas@cpan.org on 2012-02-18 22:53:20:
From cpan@barely3am.com on 2012-12-26 21:16:38:
From cpan@barely3am.com on 2012-12-27 11:50:08:
From cpan@barely3am.com on 2012-12-27 12:08:40:
From dsteinbrunner@pobox.com on 2014-03-02 19:10:26:
From dsteinbrunner@pobox.com on 2014-03-02 19:25:31:
From dsteinbrunner@pobox.com on 2014-03-04 04:19:03:
From dsteinbrunner@pobox.com on 2014-03-07 15:15:24:
The text was updated successfully, but these errors were encountered: