libwww-perl / net-http Goto Github PK
View Code? Open in Web Editor NEWLow-level HTTP client
Home Page: https://metacpan.org/pod/Net::HTTP
License: Other
net-http's People
Contributors
Stargazers
Watchers
Forkers
ilmari doy dsteinbrunner flygoast zebardy dod38fr ianburrell martineau sc0ttbeardsley lasse-unity3d andygrundman kleopatra999 kentfredric autarch saper skaji pwr22 virajkulkarni14 manwar kentnl-gentoo eserte rfilipo jkeenan trwyant paultcochrane clayne sysfce2net-http's Issues
can_read issue with Net::SSL [rt.cpan.org #98898]
Migrated from rt.cpan.org#98898 (status was 'open')
Requestors:
From [email protected] on 2014-09-15 13:09:32
:
My $work app has encountered a problem that I believe is identical to
rt#81237, but with Net::SSL rather than IO::Socket::SSL as the underlying
socket library.
Our current plan to address this is to upgrade to latest Crypt::SSLeay
(which exposed the 'pending' method in a recent change) and then apply
the following local patch (against Net-HTTP-6.06, but should apply over
6.07 as well):
--- lib/perl5/Net/HTTP/Methods.pm.old 2013-03-10 22:35:43.000000000 +0000
+++ lib/perl5/Net/HTTP/Methods.pm 2014-09-15 14:05:38.000000000 +0100
@@ -284,6 +284,7 @@
my $self = shift;
return 1 unless defined(fileno($self));
return 1 if $self->isa('IO::Socket::SSL') && $self->pending;
+ return 1 if $self->isa('Net::SSL') && $self->pending;
# With no timeout, wait forever. An explict timeout of 0 can be
# used to just check if the socket is readable without waiting.
It looks like the support for pending() came in between 0.65_02 and 0.65_04
of Crypt::SSLeay, so it isn't obvious how Net::HTTP should incorporate
a similar fix - if you're using an older Crypt::SSLeay you'll get something
like:
Can't locate object method "pending" via package "LWP::Protocol::https::Socket" at lib/perl5/Net/HTTP/Methods.pm line 287.
Hugo
From http://xlogon.net/amock on 2014-10-15 12:48:54
:
Hi all,
I'm pretty sure that I was just hit by this bug too.
I'm using LWP to make HTTP POST requests to a site.
The following combination works fast as expected:
Net::HTTP 6.01
Crypt::SSLeay 0.57
IO::Socket::INET 1.31
The follwoing combination does return after a long period (timeout):
Net::HTTP 6.06 also 6.07
Crypt::SSLeay 0.57
IO::Socket::INET 1.31
I found the same portion of code with profiling the weired test run with Devel::NYTProf showing that the call to can_read spent most of the time.
Following the proposed patch I installed newest Crypt::SSLeay and Net::HTTP, added the line and the measured runtime is as expected.
I'm writing this because I'm pretty sure that this bug happens in the wild and is a kind of backward compatibility regression of Net::HTTP.
Important is that the method 'pending' of 'Net::SSL' is introduced in one of the younger versions. The right dependencies must be set.
Regards
McA
From http://xlogon.net/amock on 2014-10-15 14:34:21
:
As an addendum:
I did some research on that to find a solution to my problem. It seems that the usage of Net::SSL as part of Crypt::SSLeay to make SSL connections is deprecated (version 0.72). As soon as you install that version the module LWP::Protocol::https is pulled from CPAN if it's not installed before. With that installation IO::Socket::SSL should be pulled from CPAN to do the whole SSL stuff in favour of Net::SSL.
So, as soon as you hit the bug you should check why you're using Net::SSL and not IO::Socket::SSL. In my case is seems to be a strange history of dependency resolution.
Regards
McA
Improve error message
At line 397 of Net/HTTP/Methods.pm it would help if the error
'Server closed connection without sending any data back'
were to include the host/remote server name, if that's available.
t/live.t started to fail
www.cpan.org is now a permanent (301) redirect to https://www.cpan.org. This is causing the t/live.t test to fail:
perl -Mblib t/live.t
1..6
# ----------------------------
# 301 Moved Permanently
# Accept-Ranges: bytes
# Connection: close
# Content-Length: 0
# Date: Fri, 01 Sep 2017 07:01:25 GMT
# Location: https://www.cpan.org/
# Retry-After: 0
# Server: Varnish
# Via: 1.1 varnish
# X-Cache: HIT
# X-Cache-Hits: 0
# X-Served-By: cache-hhn1524-HHN
# X-Timer: S1504249286.981957,VS0,VE0
#
Use of uninitialized value $buf in substitution (s///) at t/live.t line 59.
not ok 1 - success
# Failed test 'success'
# at t/live.t line 61.
not ok 2
# Failed test at t/live.t line 62.
# undef
# doesn't match '(?^:text/html)'
not ok 3
# Failed test at t/live.t line 63.
# undef
# doesn't match '(?^i:</html>)'
Server closed connection without sending any data back at /tmpfs/.cpan-build-cpansand/2017090106/Net-HTTP-6.16-0/blib/lib/Net/HTTP/Methods.pm line 391.
# Looks like you planned 6 tests but ran 3.
# Looks like you failed 3 tests of 3 run.
# Looks like your test exited with 255 just after 3.
Fails to properly parse headers for this response [rt.cpan.org #94891]
Migrated from rt.cpan.org#94891 (status was 'new')
Requestors:
From [email protected] on 2014-04-20 08:08:05:
Yahoo servers return a generic 999 error under certain conditions, but Net::HTTP is unable to parse the headers and assumes it's a 200 ok and returns the headers+gzipped content in the content field.
I don't know of a reliable way to trigger the error, so I'll just paste the response's content dump which contains the unparsed headers. Several different browsers and AnyEvent::HTTP were able to properly parse the headers and interpreted the message as a 999 error, unlike LWP/Net::HTTP.
_content => "HTTP/1.0 999 Unable to process request at this time -- error 999\r\nDate: Sun, 20 Apr 2014 07:33:57 GMT\r\nServer: Apache/2.2.22 (Ubuntu)\r\nX-Powered-By: PHP/5.3.10-1ubuntu3.11\r\nCache-Control: private, no-cache, no-store\r\nExpires: Thu, 01 Jan 1970 22:00:00 GMT\r\nPragma: no-cache\r\nVary: Accept-Encoding\r\nAge: 0\r\nSet-Cookie: flags=e0; expires=Sun, 18-May-2014 07:33:57 GMT; path=/; domain=.sweetly.tk\r\nContent-Disposition: inline; filename=""\r\nContent-Length: 3097\r\nContent-Encoding: gzip\r\nConnection: close\r\nContent-Type: text/html;charset=UTF-8\r\n\r\n ... $gzipped_content...
t/live-https.t fails a header comparison
The test at https://github.com/libwww-perl/Net-HTTP/blob/master/t/live-https.t#L75 is failing because, as of today, the content-type header returned by www.cpan.org is all lowercase.
t/live-https.t fails (Server closed connection)
Right now t/live-https.t fails (various OS, various perl versions):
perl5.30.0-RC1 -Mblib t/live-https.t
1..6
# ----------------------------
# 200 OK
# Accept-Ranges: bytes
# Age: 369
# Cache-Control: public, max-age=900, stale-while-revalidate=90, stale-if-error=172800
# Connection: close
# Content-Length: 8396
# Content-Type: text/html
# Date: Sun, 12 May 2019 17:57:10 GMT
# ETag: "20cc-588b466c17ac0"
# Last-Modified: Sun, 12 May 2019 17:48:03 GMT
# Server: Apache/2.4.29 (Unix)
# Strict-Transport-Security: max-age=15724800;
# Vary: Accept-Encoding
# Via: 1.1 varnish
# X-Cache: HIT, HIT
# X-Cache-Hits: 1, 1
# X-Served-By: cache-hhn1539-HHN, cache-hel6827-HEL
# X-Timer: S1557683831.707778,VS0,VE1
#
ok 1 - success
ok 2
ok 3
Server closed connection without sending any data back at /home/cpansand/.cpan/build/2019051219/Net-HTTP-6.18-0/blib/lib/Net/HTTP/Methods.pm line 391.
# Looks like your test exited with 255 just after 3.
An strace log is probably not that useful with encrypted connections, but here it is:
18878 19:48:57.507596 write(5, "ok 1 - success\n", 15) = 15 <0.000022>
18878 19:48:57.507903 write(5, "ok 2\n", 5) = 5 <0.000019>
18878 19:48:57.508199 write(5, "ok 3\n", 5) = 5 <0.000019>
18878 19:48:57.508341 fcntl(3, F_GETFL) = 0x2 (flags O_RDWR) <0.000011>
18878 19:48:57.508406 write(3, "\27\3\3\0|\373\324\4\257\223\260:\326\326\24\272\317.FY\370\352+\363\331\243_\247|\273S\341\310\325\3\242\"*\0378\20\354\370\230\202\v\221\314\34\241\321A4\275\315\26\333\10\222\361\204\273B}K\0es\374\224:h\335O}$)\366\24\305\251\342Hy\271\361X\\\31\20\374\345\336\245L\325}Z\252\332\373\303\210+\363I\22\350\205\2548\254\375\254\\\254\255\316\37\256\f*\t\214\241\227\23\223\331", 129) = 129 <0.000049>
18878 19:48:57.508526 select(8, [3], NULL, NULL, {15, 0}) = 1 (in [3], left {14, 999998}) <0.000012>
18878 19:48:57.508585 read(3, "\25\3\3\0\32", 5) = 5 <0.000011>
18878 19:48:57.508621 read(3, "\234z0\263)\273\343B\215x\16r\16\17F\325\32P\240\360\201\240\261\316\272 ", 26) = 26 <0.000013>
18878 19:48:57.508674 write(2, "Server closed connection without sending any data back at /home/cpansand/.cpan/build/2019051219/Net-HTTP-6.18-0/blib/lib/Net/HTTP/Methods.pm line 391.\n", 151) = 151 <0.000018>
18878 19:48:57.509582 close(3) = 0 <0.000091>
Delayed response results in 500 error [rt.cpan.org #101072]
Migrated from rt.cpan.org#101072 (status was 'new')
Requestors:
Attachments:
From [email protected] on 2014-12-21 20:08:31:
The changes made in 6.07 cause spurious problems with systems which have a high connection latency to the internet. The error returned is:
A connect request was made on an already connected socket. at C:/Strawberry/perl/vendor/lib/LWP/Protocol/http.pm line 49.
Four files are attached: TestW.pl always works (for comparison), TestF.pl always fails (see below), Error.txt is the full text of the error message, and Diff.txt is the diff between the working version (6.06) and non-working version (6.07) of HTTP.pm.
Specifically, a NAT system directly connected to the internet never sees the error, a system using a hard-line ethernet to the NAT sees the error 20% of the time, and a system using a WiFi dongle to the NAT sees the error 100% of the time.
This is not in any way a problem with the systems, the internet connections, or configurations thereof. I have included a test case that always works; additionally, version 6.06 of HTTP.pm always works, while 6.07 fails on the same system.
This is using the Strawberry perl Win32 ZIP version, on a fresh install of WinXP service pack 3 known to have no viruses.
The module HTTP.pm is used indirectly by CPAN, so this bug breaks CPAN, which is how I initially found it. A laptop connecting via WiFi to a home NAT system will be unable to run CPAN.
For comparison, note that bug #98306 refers to other problems caused by the same paragraph of code in HTTP.pm V6.07.
This problem may be difficult for to debug and test. I have machines on a NAT setup as described - if the authors/maintainers need an external test bed please contact me.
Browser interface inNet::Http-> [rt.cpan.org #56966]
Migrated from rt.cpan.org#56966 (status was 'open')
Requestors:
Attachments:
From [email protected] on 2010-04-27 11:45:20:
accounted for each browser's different data stream (when viewed using
WireShark)
From [email protected] on 2017-01-25 21:40:54:
migrated queues: libwww-perl -> Net-HTTP
From [email protected] on 2017-03-28 19:38:37:
On Tue Apr 27 07:45:20 2010, sussml wrote:
> accounted for each browser's different data stream (when viewed using
> WireShark)
Net::HTTP::Methods has evolved considerably since this ticket was filed seven years ago. If the revisions are still needed, would it be possible to create a pull request against the master branch of Net-HTTP at https://github.com/libwww-perl/Net-HTTP?
Thank you very much.
Jim Keenan
Can't fetch https response that's 1024 bytes in size
I'm using SOAP::Lite to query a SOAP service, and sometime the response (including headers) is exactly 1024 bytes long.
When this happens, the SOAP call will result in a timeout because of these lines:
https://github.com/libwww-perl/net-http/blob/master/lib/Net/HTTP/Methods.pm#L276-L279
# consume all incoming bytes
while(1) {
my $bytes_read = $self->sysread($_, 1024, length);
if(defined $bytes_read) {
$new_bytes += $bytes_read;
last if $bytes_read < 1024;
}
[...]I've got a Wireshark log of this case, which highlights this problem.
(like adding debugging statements to that piece of code).
What's the best way to fix this? I'd like to help on this issue...
t/rt-112313.t fails with 5.26.0-rc1
Seeing this on Linux and macOS...
cpanm (App::cpanminus) 1.7043 on perl 5.026000 built for darwin-2level
Work directory is /Users/genehack/.cpanm/work/1494558658.34056
You have make /usr/bin/make
You have LWP 6.26
You have /usr/bin/tar: bsdtar 2.8.3 - libarchive 2.8.3
You have /usr/bin/unzip
Searching Net::HTTP () on cpanmetadb ...
--> Working on Net::HTTP
Fetching http://www.cpan.org/authors/id/O/OA/OALDERS/Net-HTTP-6.14.tar.gz
-> OK
Unpacking Net-HTTP-6.14.tar.gz
Entering Net-HTTP-6.14
Checking configure dependencies from META.json
Checking if you have ExtUtils::MakeMaker 6.58 ... Yes (7.24)
Configuring Net-HTTP-6.14
Running Makefile.PL
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Net::HTTP
Writing MYMETA.yml and MYMETA.json
-> OK
Checking dependencies from MYMETA.json ...
Checking if you have base 0 ... Yes (2.25)
Checking if you have strict 0 ... Yes (1.11)
Checking if you have warnings 0 ... Yes (1.37)
Checking if you have Compress::Raw::Zlib 0 ... Yes (2.074)
Checking if you have Socket 0 ... Yes (2.020_03)
Checking if you have IO::Socket::INET 0 ... Yes (1.35)
Checking if you have vars 0 ... Yes (1.03)
Checking if you have Data::Dumper 0 ... Yes (2.167)
Checking if you have URI 0 ... Yes (1.71)
Checking if you have ExtUtils::MakeMaker 0 ... Yes (7.24)
Checking if you have File::Spec 0 ... Yes (3.67)
Checking if you have IO::Uncompress::Gunzip 0 ... Yes (2.074)
Checking if you have IO::Select 0 ... Yes (1.22)
Checking if you have Test::More 0 ... Yes (1.302073)
Checking if you have Carp 0 ... Yes (1.42)
Building and testing Net-HTTP-6.14
cp lib/Net/HTTP.pm blib/lib/Net/HTTP.pm
cp lib/Net/HTTP/Methods.pm blib/lib/Net/HTTP/Methods.pm
cp lib/Net/HTTP/NB.pm blib/lib/Net/HTTP/NB.pm
cp lib/Net/HTTPS.pm blib/lib/Net/HTTPS.pm
Manifying 4 pod documents
PERL_DL_NONLAZY=1 "/opt/plenv/versions/5.26.0-RC1/bin/perl5.26.0" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harne
ss(0, 'blib/lib', 'blib/arch')" t/*.t
#
# Versions for all modules listed in MYMETA.json (including optional ones):
#
# === Configure Requires ===
#
# Module Want Have
# ------------------- ---- ----
# ExtUtils::MakeMaker any 7.24
#
# === Configure Suggests ===
#
# Module Want Have
# -------- ------- ----------
# JSON::PP 2.27300 2.27400_02
#
# === Build Requires ===
#
# Module Want Have
# ------------------- ---- ----
# ExtUtils::MakeMaker any 7.24
#
# === Test Requires ===
#
# Module Want Have
# ------------------- ---- --------
# Data::Dumper any 2.167
# ExtUtils::MakeMaker any 7.24
# File::Spec any 3.67
# IO::Select any 1.22
# Socket any 2.020_03
# Test::More any 1.302073
#
# === Test Recommends ===
#
# Module Want Have
# ---------- -------- --------
# CPAN::Meta 2.120900 2.150010
#
# === Runtime Requires ===
#
# Module Want Have
# ---------------------- ---- -----
# Carp any 1.42
# Compress::Raw::Zlib any 2.074
# IO::Socket::INET any 1.35
# IO::Uncompress::Gunzip any 2.074
# URI any 1.71
# base any 2.25
# strict any 1.11
# vars any 1.03
# warnings any 1.37
#
# === Runtime Suggests ===
#
# Module Want Have
# ----------------- ---- -------
# IO::Socket any 1.38
# IO::Socket::INET6 any missing
# IO::Socket::IP any 0.38
# IO::Socket::SSL 1.38 2.048
# Symbol any 1.08
#
t/00-report-prereqs.t .. ok
t/http-nb.t ............ ok
t/http.t ............... ok
t/live-https.t ......... ok
t/live.t ............... ok
# Failed test 'reponse length increased by 1'
# at t/rt-112313.t line 104.
# got: '-2'
# expected: '1'
# Failed test 'reponse length increased by 1'
# at t/rt-112313.t line 104.
# got: '3'
# expected: '1'
# Failed test 'reponse length increased by 1'
# at t/rt-112313.t line 104.
# got: '2'
# expected: '1'
# Failed test 'reponse length increased by 1'
# at t/rt-112313.t line 104.
# got: '0'
# expected: '1'
# Failed test 'reponse length increased by 1'
# at t/rt-112313.t line 104.
# got: '2'
# expected: '1'
# Failed test 'reponse length increased by 1'
# at t/rt-112313.t line 104.
# got: '2'
# expected: '1'
# Failed test 'reponse length increased by 1'
# at t/rt-112313.t line 104.
# got: '2'
# expected: '1'
# Failed test 'reponse length increased by 1'
# at t/rt-112313.t line 104.
# got: '0'
# expected: '1'
# Failed test 'reponse length increased by 1'
# at t/rt-112313.t line 104.
# got: '2'
# expected: '1'
# Looks like you failed 9 tests of 40.
t/rt-112313.t ..........
Dubious, test returned 9 (wstat 2304, 0x900)
Failed 9/40 subtests
Test Summary Report
-------------------
t/rt-112313.t (Wstat: 2304 Tests: 40 Failed: 9)
Failed tests: 4, 6, 8, 10, 12, 19, 30, 36, 40
Non-zero exit status: 9
Files=6, Tests=104, 26 wallclock secs ( 0.05 usr 0.02 sys + 0.65 cusr 0.10 csys = 0.82 CPU)
Result: FAIL
Failed 1/6 test programs. 9/104 subtests failed.
make: *** [test_dynamic] Error 9
version 6.07 does not work with IO::Socket::INET6 [rt.cpan.org #98306]
Migrated from rt.cpan.org#98306 (status was 'new')
Requestors:
From [email protected] on 2014-08-25 09:05:24:
- Perl version independend
- OS independend
This happens 100% on systems which supports IPv6 but has not a bound IPv6
address except localhost (::1) and on systems without any IPv6 support.
This was not verfied on a system with fully configured IPv6.
If IO::Socket::INET6 is installed but IO::Socket::IP is not - even the
make tests are failing and the module is no longer working anymore.
If IO::Socket::INET6 is uninstalled, the module is working fine in any
case.
This is related to the changes 6.06 -> 6.07
$VERSION = "6.07";
unless ($SOCKET_CLASS) {
# Try several, in order of capability and preference
if (eval { require IO::Socket::IP }) {
$SOCKET_CLASS = "IO::Socket::IP"; # IPv4+IPv6
} elsif (eval { require IO::Socket::INET6 }) {
$SOCKET_CLASS = "IO::Socket::INET6"; # IPv4+IPv6
} elsif (eval { require IO::Socket::INET }) {
$SOCKET_CLASS = "IO::Socket::INET"; # IPv4 only
} else {
require IO::Socket;
$SOCKET_CLASS = "IO::Socket::INET";
}
}
This is the dmake output from windows
c:\Perl\cpan\build\Net-HTTP-6.07>dmake test
C:\Perl\bin\perl.exe "-MExtUtils::Command::MM" "-MTest::Harness" "-e"
"undef *Test::Harness::Switches; test_harness(0,blib\lib', 'blib\arch')"
t/*.tt/apache-https.t .. print() on unopened filehandle GEN1 at
C:/Perl/lib/IO/Handle.pm line 472.
sysread() on unopened filehandle GEN1 at C:/Perl/lib/IO/Handle.pm line
465.
Status read failed: Bad file descriptor at
C:\Perl\cpan\build\Net-HTTP-6.07\blib\lib/Net/HTTP/Methods.pm line 276.
t/apache-https.t .. Dubious, test returned 9 (wstat 2304, 0x900)
Failed 8/8 subtests
t/apache.t ........ print() on unopened filehandle GEN1 at
C:/Perl/lib/IO/Handle.pm line 417.
sysread() on unopened filehandle GEN1 at C:/Perl/lib/IO/Handle.pm line
465.
Status read failed: Bad file descriptor at
C:\Perl\cpan\build\Net-HTTP-6.07\blib\lib/Net/HTTP/Methods.pm line 276.
t/apache.t ........ Dubious, test returned 9 (wstat 2304, 0x900)
Failed 8/8 subtests
t/http-nb.t ....... skipped: This test doesn't work on Windows
t/http.t .......... ok
Test Summary Report
-------------------
t/apache-https.t (Wstat: 2304 Tests: 0 Failed: 0)
Non-zero exit status: 9
Parse errors: Bad plan. You planned 8 tests but ran 0.
t/apache.t (Wstat: 2304 Tests: 0 Failed: 0)
Non-zero exit status: 9
Parse errors: Bad plan. You planned 8 tests but ran 0.
Files=4, Tests=37, 4 wallclock secs ( 0.09 usr + 0.06 sys = 0.16 CPU)
Result: FAIL
Failed 2/4 test programs. 0/37 subtests failed.
dmake.exe: Error code 255, while making 'test_dynamic'
It would be nice to have an option to preselect the $SOCKET_CLASS to use
at module load time, at least before the call to Net::HTTP->new() or as an
option in this call.
Now, setting $Net::HTTP::SOCKET_CLASS to any value before 'use Net::HTTP'
or 'require Net::HTTP' is useless, changing it after 'use' or 'require'
does not change @Net::HTTP::ISA - these variables are all not exported.
Thomas
DISCLAIMER:
*******************************************************
This email and any files transmitted with it may be confidential, legally
privileged and protected in law and are intended solely for the use of the
individual to whom it is addressed.
This email was multiple times scanned for viruses. There should be no
known virus in this email!
*******************************************************
Live tests fail for v6.14 on Windows 10 Strawberry Perl 5.24.1.1 behind HPE firewall
Installing 6.13 works fine. I am behind a restrictive outbound firewall with a proxy for external access, http_proxy and https_proxy are set correctly
Perl -V
Summary of my perl5 (revision 5 version 24 subversion 1) configuration:
Platform:
osname=MSWin32, osvers=6.3, archname=MSWin32-x64-multi-thread
uname='Win32 strawberry-perl 5.24.1.1 #1 Mon Jan 16 02:00:29 2017 x64'
config_args='undef'
hint=recommended, useposix=true, d_sigaction=undef
useithreads=define, usemultiplicity=define
use64bitint=define, use64bitall=undef, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags =' -s -O2 -DWIN32 -DWIN64 -DCONSERVATIVE -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fwrapv -fno-strict-aliasing -mms-bitfields',
optimize='-s -O2',
cppflags='-DWIN32'
ccversion='', gccversion='4.9.2', gccosandvers=''
intsize=4, longsize=4, ptrsize=8, doublesize=8, byteorder=12345678, doublekind=3
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16, longdblkind=3
ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='long long', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='g++', ldflags ='-s -L"C:\STRAWB~1\perl\lib\CORE" -L"C:\STRAWB~1\c\lib"'
libpth=C:\STRAWB~1\c\lib C:\STRAWB~1\c\x86_64-w64-mingw32\lib C:\STRAWB~1\c\lib\gcc\x86_64-w64-mingw32\4.9.2
libs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
perllibs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
libc=, so=dll, useshrplib=true, libperl=libperl524.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_win32.xs, dlext=xs.dll, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags='-mdll -s -L"C:\STRAWB~1\perl\lib\CORE" -L"C:\STRAWB~1\c\lib"'
Characteristics of this binary (from libperl):
Compile-time options: HAS_TIMES HAVE_INTERP_INTERN MULTIPLICITY
PERLIO_LAYERS PERL_COPY_ON_WRITE
PERL_DONT_CREATE_GVSV
PERL_HASH_FUNC_ONE_AT_A_TIME_HARD
PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS
PERL_MALLOC_WRAP PERL_PRESERVE_IVUV USE_64_BIT_INT
USE_ITHREADS USE_LARGE_FILES USE_LOCALE
USE_LOCALE_COLLATE USE_LOCALE_CTYPE
USE_LOCALE_NUMERIC USE_LOCALE_TIME USE_PERLIO
USE_PERL_ATOF
Built under MSWin32
Compiled at Jan 16 2017 02:12:13
@INC:
C:/Strawberry/perl/site/lib/MSWin32-x64-multi-thread
C:/Strawberry/perl/site/lib
C:/Strawberry/perl/vendor/lib
C:/Strawberry/perl/lib
.
cpanm Net::[email protected]
cpanm (App::cpanminus) 1.7043 on perl 5.024001 built for MSWin32-x64-multi-thread
Work directory is C:\Users\rpeter/.cpanm/work/1493136176.12116
You have make C:\Strawberry\c\bin\dmake.exe
You have LWP 6.26
Falling back to Archive::Tar 2.24
Searching Net::HTTP (== 6.14) on cpanmetadb ...
--> Working on Net::HTTP
Fetching http://www.cpan.org/authors/id/O/OA/OALDERS/Net-HTTP-6.14.tar.gz
-> OK
Unpacking Net-HTTP-6.14.tar.gz
Entering Net-HTTP-6.14
Checking configure dependencies from META.json
Checking if you have ExtUtils::MakeMaker 6.58 ... Yes (7.24)
Configuring Net-HTTP-6.14
Running Makefile.PL
Checking if your kit is complete...
Looks good
Generating a dmake-style Makefile
Writing Makefile for Net::HTTP
Writing MYMETA.yml and MYMETA.json
-> OK
Checking dependencies from MYMETA.json ...
Checking if you have IO::Socket::INET 0 ... Yes (1.35)
Checking if you have IO::Uncompress::Gunzip 0 ... Yes (2.070)
Checking if you have warnings 0 ... Yes (1.36)
Checking if you have Data::Dumper 0 ... Yes (2.161)
Checking if you have Test::More 0 ... Yes (1.302083)
Checking if you have strict 0 ... Yes (1.11)
Checking if you have File::Spec 0 ... Yes (3.63_01)
Checking if you have base 0 ... Yes (2.23)
Checking if you have Carp 0 ... Yes (1.40)
Checking if you have Socket 0 ... Yes (2.024)
Checking if you have Compress::Raw::Zlib 0 ... Yes (2.071)
Checking if you have IO::Select 0 ... Yes (1.22)
Checking if you have ExtUtils::MakeMaker 0 ... Yes (7.24)
Checking if you have URI 0 ... Yes (1.71)
Checking if you have vars 0 ... Yes (1.03)
Building and testing Net-HTTP-6.14
cp lib/Net/HTTP/NB.pm blib\lib\Net\HTTP\NB.pm
cp lib/Net/HTTPS.pm blib\lib\Net\HTTPS.pm
cp lib/Net/HTTP.pm blib\lib\Net\HTTP.pm
cp lib/Net/HTTP/Methods.pm blib\lib\Net\HTTP\Methods.pm
"C:\Strawberry\perl\bin\perl.exe" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib\lib', 'blib\arch')" t/*.t
#
# Versions for all modules listed in MYMETA.json (including optional ones):
#
# === Configure Requires ===
#
# Module Want Have
# ------------------- ---- ----
# ExtUtils::MakeMaker any 7.24
#
# === Configure Suggests ===
#
# Module Want Have
# -------- ------- -------
# JSON::PP 2.27300 2.27400
#
# === Build Requires ===
#
# Module Want Have
# ------------------- ---- ----
# ExtUtils::MakeMaker any 7.24
#
# === Test Requires ===
#
# Module Want Have
# ------------------- ---- --------
# Data::Dumper any 2.161
# ExtUtils::MakeMaker any 7.24
# File::Spec any 3.63_01
# IO::Select any 1.22
# Socket any 2.024
# Test::More any 1.302083
#
# === Test Recommends ===
#
# Module Want Have
# ---------- -------- --------
# CPAN::Meta 2.120900 2.150010
#
# === Runtime Requires ===
#
# Module Want Have
# ---------------------- ---- -----
# Carp any 1.40
# Compress::Raw::Zlib any 2.071
# IO::Socket::INET any 1.35
# IO::Uncompress::Gunzip any 2.070
# URI any 1.71
# base any 2.23
# strict any 1.11
# vars any 1.03
# warnings any 1.36
#
# === Runtime Suggests ===
#
# Module Want Have
# ----------------- ---- -----
# IO::Socket any 1.38
# IO::Socket::INET6 any 2.72
# IO::Socket::IP any 0.38
# IO::Socket::SSL 1.38 2.043
# Symbol any 1.07
#
t/00-report-prereqs.t .. ok
t/http-nb.t ............ skipped: This test doesn't work on Windows
t/http.t ............... ok
Bad file descriptor at t/live-https.t line 34.
# Looks like your test exited with 9 before it could output anything.
t/live-https.t .........
Dubious, test returned 9 (wstat 2304, 0x900)
Failed 6/6 subtests
Server closed connection without sending any data back at C:\Users\rpeter\.cpanm\work\1493136176.12116\Net-HTTP-6.14\blib\lib/Net/HTTP/Methods.pm line 391.
# Looks like your test exited with 255 just after 3.
t/live.t ...............
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 3/6 subtests
# Failed test 'base response length is less than 1024: 11847'
# at t/rt-112313.t line 84.
Negative repeat count does nothing at t/rt-112313.t line 50.
Negative repeat count does nothing at t/rt-112313.t line 50.
# Failed test 'reponse length increased by 1'
# at t/rt-112313.t line 104.
# got: '0'
# expected: '1'
Negative repeat count does nothing at t/rt-112313.t line 50.
# Failed test 'reponse length increased by 1'
# at t/rt-112313.t line 104.
# got: '0'
# expected: '1'
Negative repeat count does nothing at t/rt-112313.t line 50.
# Failed test 'reponse length increased by 1'
# at t/rt-112313.t line 104.
# got: '0'
# expected: '1'
Negative repeat count does nothing at t/rt-112313.t line 50.
# Failed test 'reponse length increased by 1'
# at t/rt-112313.t line 104.
# got: '0'
# expected: '1'
Negative repeat count does nothing at t/rt-112313.t line 50.
# Failed test 'reponse length increased by 1'
# at t/rt-112313.t line 104.
# got: '0'
# expected: '1'
Negative repeat count does nothing at t/rt-112313.t line 50.
# Failed test 'reponse length increased by 1'
# at t/rt-112313.t line 104.
# got: '0'
# expected: '1'
Negative repeat count does nothing at t/rt-112313.t line 50.
Negative repeat count does nothing at t/rt-112313.t line 50.
# Failed test 'reponse length increased by 1'
# at t/rt-112313.t line 104.
# got: '0'
# expected: '1'
Negative repeat count does nothing at t/rt-112313.t line 50.
# Failed test 'reponse length increased by 1'
# at t/rt-112313.t line 104.
# got: '0'
# expected: '1'
Negative repeat count does nothing at t/rt-112313.t line 50.
# Failed test 'reponse length increased by 1'
# at t/rt-112313.t line 104.
# got: '0'
# expected: '1'
Negative repeat count does nothing at t/rt-112313.t line 50.
# Failed test 'reponse length increased by 1'
# at t/rt-112313.t line 104.
# got: '0'
# expected: '1'
Negative repeat count does nothing at t/rt-112313.t line 50.
# Failed test 'reponse length increased by 1'
# at t/rt-112313.t line 104.
# got: '0'
# expected: '1'
Negative repeat count does nothing at t/rt-112313.t line 50.
# Failed test 'reponse length increased by 1'
# at t/rt-112313.t line 104.
# got: '0'
# expected: '1'
Negative repeat count does nothing at t/rt-112313.t line 50.
Negative repeat count does nothing at t/rt-112313.t line 50.
# Failed test 'reponse length increased by 1'
# at t/rt-112313.t line 104.
# got: '0'
# expected: '1'
Negative repeat count does nothing at t/rt-112313.t line 50.
# Failed test 'reponse length increased by 1'
# at t/rt-112313.t line 104.
# got: '0'
# expected: '1'
Negative repeat count does nothing at t/rt-112313.t line 50.
# Failed test 'reponse length increased by 1'
# at t/rt-112313.t line 104.
# got: '0'
# expected: '1'
Negative repeat count does nothing at t/rt-112313.t line 50.
# Failed test 'reponse length increased by 1'
# at t/rt-112313.t line 104.
# got: '0'
# expected: '1'
Negative repeat count does nothing at t/rt-112313.t line 50.
# Failed test 'reponse length increased by 1'
# at t/rt-112313.t line 104.
# got: '0'
# expected: '1'
Negative repeat count does nothing at t/rt-112313.t line 50.
# Failed test 'reponse length increased by 1'
# at t/rt-112313.t line 104.
# got: '0'
# expected: '1'
# Looks like you failed 19 tests of 40.
t/rt-112313.t ..........
Dubious, test returned 19 (wstat 4864, 0x1300)
Failed 19/40 subtests
Test Summary Report
-------------------
t/live-https.t (Wstat: 2304 Tests: 0 Failed: 0)
Non-zero exit status: 9
Parse errors: Bad plan. You planned 6 tests but ran 0.
t/live.t (Wstat: 65280 Tests: 3 Failed: 0)
Non-zero exit status: 255
Parse errors: Bad plan. You planned 6 tests but ran 3.
t/rt-112313.t (Wstat: 4864 Tests: 40 Failed: 19)
Failed tests: 1, 4, 6, 8, 10, 12, 14, 17, 19, 21, 23
25, 27, 30, 32, 34, 36, 38, 40
Non-zero exit status: 19
Files=6, Tests=81, 26 wallclock secs ( 0.02 usr + 0.02 sys = 0.03 CPU)
Result: FAIL
Failed 3/6 test programs. 19/81 subtests failed.
dmake.exe: Error code 147, while making 'test_dynamic'
-> FAIL Installing Net::HTTP failed. See C:\Users\rpeter\.cpanm\work\1493136176.12116\build.log for details. Retry with --force to force install it.
SSL module negotiation [rt.cpan.org #29704]
Migrated from rt.cpan.org#29704 (status was 'open')
Requestors:
Attachments:
From [email protected] on 2007-10-02 00:46:50:
It appears there is a bug in your SSL module negotiation. While the
documentation stats Crypt::SSLeay is preferred, IO::Socket::SSL will be
used instead if loaded. I came across this after trying to determine
why some P12 SSL transactions were failing. The cause was found to be
having loaded IMAP::Client which loaded IO::Socket::SSL; Crypt::SSLeay
uses env vars for P12 but IO::Socket::SSL doesn't seem to honor the same
vars.
This illustrates the problem:
perl -e 'use Net::SSL;use Crypt::SSLeay; use IO::Socket::SSL; use
Net::HTTPS; print $Net::HTTPS::SSL_SOCKET_CLASS,"\n";'
It seems that the Net::SSL::VERSION is not being set until after using
all the modules where IO::Socket::SSL::VERSION is being set. The
difference I think is that IO::Socket::SSL::VERSION uses a BEGIN block
to set the Version where Net::SSL does not.
Now that I have found my issue there are many work-a-rounds, but this
was quite difficult to track down so I thought I'd let you know.
Aaron Mefford
Software Developement Manager
United Online Webservices
Desk: 801.437.6055
AIM: aaronmefford
From [email protected] on 2017-01-25 21:42:11:
migrated queues: libwww-perl -> Net-HTTPS
From [email protected] on 2017-03-28 20:01:04:
On Mon Oct 01 20:46:50 2007, [email protected] wrote:
> It appears there is a bug in your SSL module negotiation. While the
> documentation stats Crypt::SSLeay is preferred, IO::Socket::SSL will be
> used instead if loaded. I came across this after trying to determine
> why some P12 SSL transactions were failing. The cause was found to be
> having loaded IMAP::Client which loaded IO::Socket::SSL; Crypt::SSLeay
> uses env vars for P12 but IO::Socket::SSL doesn't seem to honor the same
> vars.
>
>
>
> This illustrates the problem:
>
> perl -e 'use Net::SSL;use Crypt::SSLeay; use IO::Socket::SSL; use
> Net::HTTPS; print $Net::HTTPS::SSL_SOCKET_CLASS,"\n";'
>
>
>
> It seems that the Net::SSL::VERSION is not being set until after using
> all the modules where IO::Socket::SSL::VERSION is being set. The
> difference I think is that IO::Socket::SSL::VERSION uses a BEGIN block
> to set the Version where Net::SSL does not.
>
>
>
> Now that I have found my issue there are many work-a-rounds, but this
> was quite difficult to track down so I thought I'd let you know.
>
>
>
> Aaron Mefford
>
> Software Developement Manager
>
> United Online Webservices
>
> Desk: 801.437.6055
>
> AIM: aaronmefford
>
>
>
Current status, running file attached.
#####
$ perl cpan-29704.pl
Perl version: v5.24.1
$Net::SSL::VERSION 2.86
$Crypt::SSLeay::VERSION 0.72
$IO::Socket::SSL::VERSION 2.043
$Net::HTTPS::VERSION 6.12
$Net::HTTPS::SSL_SOCKET_CLASS: IO::Socket::SSL
#####
But if I comment out the lines referring to IO::Socket::SSL, I get:
#####
$ perl cpan-29704-no-io-socket-ssl.pl
Perl version: v5.24.1
$Net::SSL::VERSION 2.86
$Crypt::SSLeay::VERSION 0.72
$Net::HTTPS::VERSION 6.12
$Net::HTTPS::SSL_SOCKET_CLASS: Net::SSL
#####
Hence, problem persists.
Thank you very much.
Jim Keenan
From [email protected] on 2017-03-28 20:02:23:
On Tue Mar 28 16:01:04 2017, JKEENAN wrote:
> On Mon Oct 01 20:46:50 2007, [email protected] wrote:
> > It appears there is a bug in your SSL module negotiation. While the
> > documentation stats Crypt::SSLeay is preferred, IO::Socket::SSL will be
> > used instead if loaded. I came across this after trying to determine
> > why some P12 SSL transactions were failing. The cause was found to be
> > having loaded IMAP::Client which loaded IO::Socket::SSL; Crypt::SSLeay
> > uses env vars for P12 but IO::Socket::SSL doesn't seem to honor the same
> > vars.
> >
> >
> >
> > This illustrates the problem:
> >
> > perl -e 'use Net::SSL;use Crypt::SSLeay; use IO::Socket::SSL; use
> > Net::HTTPS; print $Net::HTTPS::SSL_SOCKET_CLASS,"\n";'
> >
> >
> >
> > It seems that the Net::SSL::VERSION is not being set until after using
> > all the modules where IO::Socket::SSL::VERSION is being set. The
> > difference I think is that IO::Socket::SSL::VERSION uses a BEGIN block
> > to set the Version where Net::SSL does not.
> >
> >
> >
> > Now that I have found my issue there are many work-a-rounds, but this
> > was quite difficult to track down so I thought I'd let you know.
> >
> >
> >
> > Aaron Mefford
> >
> > Software Developement Manager
> >
> > United Online Webservices
> >
> > Desk: 801.437.6055
> >
> > AIM: aaronmefford
> >
> >
> >
>
> Current status, running file attached.
> #####
> $ perl cpan-29704.pl
> Perl version: v5.24.1
> $Net::SSL::VERSION 2.86
> $Crypt::SSLeay::VERSION 0.72
> $IO::Socket::SSL::VERSION 2.043
> $Net::HTTPS::VERSION 6.12
>
> $Net::HTTPS::SSL_SOCKET_CLASS: IO::Socket::SSL
> #####
>
> But if I comment out the lines referring to IO::Socket::SSL, I get:
>
> #####
> $ perl cpan-29704-no-io-socket-ssl.pl
> Perl version: v5.24.1
> $Net::SSL::VERSION 2.86
> $Crypt::SSLeay::VERSION 0.72
> $Net::HTTPS::VERSION 6.12
>
> $Net::HTTPS::SSL_SOCKET_CLASS: Net::SSL
> #####
>
> Hence, problem persists.
>
> Thank you very much.
> Jim Keenan
First file attached was incorrect; correcting.
Problems installing on macOS
After cpanm LWP, I get the following error:
--> Working on LWP
Fetching http://www.cpan.org/authors/id/O/OA/OALDERS/libwww-perl-6.50.tar.gz ... OK
Configuring libwww-perl-6.50 ... OK
==> Found dependencies: Net::HTTP
--> Working on Net::HTTP
Fetching http://www.cpan.org/authors/id/O/OA/OALDERS/Net-HTTP-6.19.tar.gz ... OK
Configuring Net-HTTP-6.19 ... OK
Building and testing Net-HTTP-6.19 ... FAIL
which leads to this except from the log file:
t/http.t ............... ok
Net::HTTPS: SSL connect attempt failed with unknown error error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version at t/live-https.t line 34.
# Looks like your test exited with 255 before it could output anything.
t/live-https.t .........
Dubious, test returned 255 (wstat 65280, 0xff00)
Something I can fix here? :)
Net::HTTP should not depend on Net::SSL
I realize that Net::HTTP allows an existing Net::SSL to be used for HTTPS connections, but I don't think that is a good reason to list what has always been a very incomplete implementation as a requirement.
Warning when producing an error message
In lib/Net/HTTP/Methods.pm line 528, you can find
die "Missing newline after chunk data: '$line'"
if !defined($line) || $line ne "";On an transmission error, we got
Use of uninitialized value $line in concatenation (.) or string at Net/HTTP/Methods.pm line 528.The logic seems incorrect:
die "Missing newline after chunk data: '$line'"
if defined $line && $line ne '';read_entity_body() should warn() if Content-Length is less than the size of the payload.
https://tools.ietf.org/html/rfc2616#page-34
The last paragraph of RFC 2616/4.4 stipulates that a notification (warn() in Perl, ISTM) should be given when the payload length doesnโt match the Content-Length header.
Right now thereโs no such warn() happening โฆ maybe do a recv()/MSG_PEEK to see if there is more to read on the socket, then warn() if so?
Can't decide a runtime if I need to use SSL [rt.cpan.org #83024]
Migrated from rt.cpan.org#83024 (status was 'new')
Requestors:
From [email protected] on 2013-01-29 10:15:13:
I am getting
Can't locate object method "configure" via package "Net::HTTPS" at
/usr/local/share/perl/5.10.1/Net/HTTPS.pm
if I specify
"$Net::HTTPS::SSL_SOCKET_CLASS = "IO::Socket::SSL";"
but don't require/use IO::Socket::SSL
if I require IO::Socket::SSL somewhere in conditional block, I am getting
lot's of weird errors like
IO::Socket::SSL::BEGIN(/usr/local/lib/perl/5.10.1/Net/SSLeay.pm:0)
(eval)(/usr/local/share/perl/5.10.1/IO/Socket/SSL.pm:18)
(eval)(/usr/local/lib/perl/5.10.1/Net/SSLeay.pm:367)
XSLoader::load(/usr/local/lib/perl/5.10.1/Net/SSLeay.pm:365)
(eval)(/usr/lib/perl/5.10/XSLoader.pm:94)
main::__ANON__(/usr/lib/perl/5.10/XSLoader.pm:94)
Fatal Error: 1 Can't locate object method "tid" via package "threads" at
/usr/lib/perl/5.10/XSLoader.pm line 94, <GEN3> line 1.
So I cannot write a code which loads SSL modules (which I want) only if
user wants to use SSL.
LWP/Net::HTTPS 6.04
IO::Socket::SSL 1.81
Net::HTTP::NB bug with chunked responses when there is a delay around the chunk header [rt.cpan.org #107744]
Migrated from rt.cpan.org#107744 (status was 'open')
Requestors:
Attachments:
From [email protected] on 2015-10-13 07:51:31
:
Net::HTTP::NB v6.09
Net::HTTP::Methods v6.09
OS: RedHat 6.7 on x86_64
Dear Net::HTTP developers,
I have discovered a bug in Net::HTTP::NB if the server it connects to responds with chunked data and the client cannot read the chunk length field *and* at least 1 byte of the data in a single call to read_entity_body().
The details of the bug are as follows:
When Net::HTTP::NB::read_entity_body() calls Net::HTTP::Methods::read_entity_body() for the first time, the Transfer-Encoding headers are inspected. If chunked mode is to be used, the chunk length is read (line 534) and the data is read (line 571). This all works fine if the data buffer has sufficient data already within it for both reads. If there is insufficient data to complete either or both reads then a second call is made to Net::HTTP::NB::sysread() and this causes the "Multi-Read" die() on line 16 after restoring the original data buffer from "httpnb_save".
When Net::HTTP::NB::read_entity_body() is retried, the call to Net::HTTP::Methods::read_entity_body() skips the header inspection because "http_first_body" was reset to zero on the first attempt. This means that it assumes that the data is not chunked and just reads all the data as the content, ignoring any chunked encoding.
I believe that the solution is to preserve and restore "http_first_body" and "http_request_method" around the "eval { }" block in Net::HTTP::NB::read_entity_body() so that subsequent retry attempts to Net::HTTP::Methods::read_entity_body() correctly restore its state if an error occurs.
I have attached two test utilities that trigger the bug and validate the patch.
The first, test-http-server.pl, is a small web server that can chunk its response into configurable sizes and can also flush and pause its output at configurable data positions. This is used to cause specific jitter patterns in the web server response so that we can reliably exercise the various paths through the client.
The second, test-http-async-2.pl, is a small client using HTTP::Async that performs a set of tests against the web server with different chunked/non-chunked encodings and with different delay patterns. The client knows what web response to expect so it uses a SHA-1 digest to validate the response.
I have also attached a patch for Net::HTTP::NB which causes all tests to pass on my machine.
I apologise for renaming all files with a .txt extension but our email uses Microsoft Outlook and this often blocks extensions that it doesn't think are safe. Renaming files to .txt means that they always get through.
As an FYI, this bug was original spotted with Net::HTTPS::NB when working with an HTTPS connection. That part of the code in Net::HTTPS::NB was copied from Net::HTTP::NB and the investigation continued to find the root cause as described above. I'll be offering an similar patch to the Net::HTTPS::NB developers.
Best regards,
Roger Lucas
From [email protected] on 2015-10-14 05:10:10
:
On Tue Oct 13 03:51:31 2015, [email protected] wrote:
> Net::HTTP::NB v6.09
> Net::HTTP::Methods v6.09
> OS: RedHat 6.7 on x86_64
>
> Dear Net::HTTP developers,
>
> I have discovered a bug in Net::HTTP::NB if the server it connects to
> responds with chunked data and the client cannot read the chunk length
> field *and* at least 1 byte of the data in a single call to
> read_entity_body().
>
> The details of the bug are as follows:
>
> When Net::HTTP::NB::read_entity_body() calls
> Net::HTTP::Methods::read_entity_body() for the first time, the
> Transfer-Encoding headers are inspected. If chunked mode is to be
> used, the chunk length is read (line 534) and the data is read (line
> 571). This all works fine if the data buffer has sufficient data
> already within it for both reads. If there is insufficient data to
> complete either or both reads then a second call is made to
> Net::HTTP::NB::sysread() and this causes the "Multi-Read" die() on
> line 16 after restoring the original data buffer from "httpnb_save".
>
> When Net::HTTP::NB::read_entity_body() is retried, the call to
> Net::HTTP::Methods::read_entity_body() skips the header inspection
> because "http_first_body" was reset to zero on the first attempt.
> This means that it assumes that the data is not chunked and just reads
> all the data as the content, ignoring any chunked encoding.
>
> I believe that the solution is to preserve and restore
> "http_first_body" and "http_request_method" around the "eval { }"
> block in Net::HTTP::NB::read_entity_body() so that subsequent retry
> attempts to Net::HTTP::Methods::read_entity_body() correctly restore
> its state if an error occurs.
>
> I have attached two test utilities that trigger the bug and validate
> the patch.
>
> The first, test-http-server.pl, is a small web server that can chunk
> its response into configurable sizes and can also flush and pause its
> output at configurable data positions. This is used to cause specific
> jitter patterns in the web server response so that we can reliably
> exercise the various paths through the client.
>
> The second, test-http-async-2.pl, is a small client using HTTP::Async
> that performs a set of tests against the web server with different
> chunked/non-chunked encodings and with different delay patterns. The
> client knows what web response to expect so it uses a SHA-1 digest to
> validate the response.
>
> I have also attached a patch for Net::HTTP::NB which causes all tests
> to pass on my machine.
>
> I apologise for renaming all files with a .txt extension but our email
> uses Microsoft Outlook and this often blocks extensions that it
> doesn't think are safe. Renaming files to .txt means that they always
> get through.
>
> As an FYI, this bug was original spotted with Net::HTTPS::NB when
> working with an HTTPS connection. That part of the code in
> Net::HTTPS::NB was copied from Net::HTTP::NB and the investigation
> continued to find the root cause as described above. I'll be offering
> an similar patch to the Net::HTTPS::NB developers.
>
> Best regards,
>
> Roger Lucas
With Roger we found that his patch doesn't cover all cases. This test server and client demonstrates problem: https://gist.github.com/olegwtf/c4dc83711c03a66ba07a
So, I reworked his patch a little and now it seems it looks good for both of us.
Net::HTTP 500 readtimeout [rt.cpan.org #86119]
Migrated from rt.cpan.org#86119 (status was 'new')
Requestors:
From [email protected] on 2013-06-13 19:06:52:
http://www.perlmonks.org/?node_id=1038388
For some reason, I'm getting timeout when trying to consume a Restful webservice. There's no proxy issue or login because I was able to write a php snipplet and consume the webservice on the same machine. The web server is sending responses in "chunked".
It all boiled down to the line 257 on Net::HTTP::Methods.
Interaction between keep-alive, http 1.0 client and 1.1 server [rt.cpan.org #104430]
Migrated from rt.cpan.org#104430 (status was 'new')
Requestors:
From [email protected] on 2015-05-14 13:34:02:
Hi,
I've got a problem getting keep-alives to work with an XML-RPC client that
I believe to be due to a bug in Net::HTTP. I'm using version 6.06, but I
can't see any significant differences in this area between that version
and the latest, 6.08_002.
What's happening is this:
1st request
-----------
Client make a connection to the server.
Client sends request in HTTP/1.0 with Keep-Alive: 300 and Connection: Keep-Alive.
Server sends response in HTTP/1.1 with Connection: Keep-Alive.
2nd request
-----------
Client sends request in HTTP/1.0 with no Keep-Alive: or Connection: headers.
Server sends response in HTTP/1.1 with no Connection: Keep-Alive.
3rd request
-----------
Client discovers that the socket is marked readable (I think the server
has closed the connection already) so it closes the connection.
Client makes a new connection to the server.
Client sends request in HTTP/1.0 with Keep-Alive: 300 and Connection: Keep-Alive.
Server sends response in HTTP/1.1 with Connection: Keep-Alive.
etc.
4th request
-----------
Client sends request in HTTP/1.0 with no Keep-Alive: or Connection: headers.
Server sends response in HTTP/1.1 with no Connection: Keep-Alive.
The behaviour is that the client alternates between using, and not using,
keep-alives.
The server's first response is 1.1 and without Connection: close so the
socket is legitimately considered for re-use. However, the client doesn't
explicitly request on the next request Keep-Alive because the server is
1.1. The server's second response results in the connection being closed
because the client is 1.0 and it didn't request keep-alive. I think the
server is behaving correctly, and that is was an error not to emit
Connection: keep-alive when making a 1.0 request.
The relevant section of code is this: (Net/HTTP/Methods.pm)
unless (grep lc($_) eq "close", @connection) {
if ($self->keep_alive) {
if ($peer_ver eq "1.0") {
# from looking at Netscape's headers
push(@h2, "Keep-Alive: 300");
unshift(@connection, "Keep-Alive");
}
}
else {
push(@connection, "close") if $ver ge "1.1";
}
}
If I've understood LWP correctly, the fact that the socket was deposited
into the connection cache at all means that the socket is eligible for
re-use. It doesn't need further tests because it was put there by
LWP::Protocol::http.pm on the basis of the http version and connection
header in the response.
In Net/HTTP/Methods.pm, I believe that it is only necessary to focus on how
to advertise that we would like the next response to keep the
connection open, so the test, 'if ($peer_ver eq "1.0")', should actually
be looking at the http version _we_ are using, not the version that the
peer is using. In other words, the code above should be along the lines of:
if ($self->keep_alive && $ver eq '1.0') {
push(@h2, "Keep-Alive: 300");
unshift(@connection, "Keep-Alive");
}
Peter
rt-112313 .t failing on timeout
Occasionally the request won't be able to be done within the current timeout of 15s and it'll fail pretty spectacularly:
errietta@Moltres [2] ~/Net-HTTP-6.15 % perl -Ilib -I/home/errietta/deps/lib/perl5 -I/home/errietta/deps t/rt-112313.t 0 3092 20:21:15 Wed 17.05.2017
{
"headers": {
"Connection": "close",
"Host": "httpbin.org",
"User-Agent": "Net::HTTP - t/rt-112313.t",
"X-Foo": "x"
}
}
ok 1 - base response length is less than 1024: 410
{
"headers": {
"Connection": "close",
"Host": "httpbin.org",
"User-Agent": "Net::HTTP - t/rt-112313.t",
"X-Foo": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
ok 2 - ok for n 611 -> response length 1020
{
"headers": {
"Connection": "close",
"Host": "httpbin.org",
"User-Agent": "Net::HTTP - t/rt-112313.t",
"X-Foo": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
ok 3 - ok for n 612 -> response length 1021
ok 4 - reponse length increased by 1
{
"headers": {
"Connection": "close",
"Host": "httpbin.org",
"User-Agent": "Net::HTTP - t/rt-112313.t",
"X-Foo": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
ok 5 - ok for n 613 -> response length 1022
ok 6 - reponse length increased by 1
{
"headers": {
"Connection": "close",
"Host": "httpbin.org",
"User-Agent": "Net::HTTP - t/rt-112313.t",
"X-Foo": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
ok 7 - ok for n 614 -> response length 1023
ok 8 - reponse length increased by 1
{
"headers": {
"Connection": "close",
"Host": "httpbin.org",
"User-Agent": "Net::HTTP - t/rt-112313.t",
"X-Foo": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
ok 9 - ok for n 615 -> response length 1024
ok 10 - reponse length increased by 1
{
"headers": {
"Connection": "close",
"Host": "httpbin.org",
"User-Agent": "Net::HTTP - t/rt-112313.t",
"X-Foo": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
ok 11 - ok for n 616 -> response length 1025
ok 12 - reponse length increased by 1
{
"headers": {
"Connection": "close",
"Host": "httpbin.org",
"User-Agent": "Net::HTTP - t/rt-112313.t",
"X-Foo": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
ok 13 - ok for n 617 -> response length 1026
ok 14 - reponse length increased by 1
{
"headers": {
"Connection": "close",
"Host": "httpbin.org",
"User-Agent": "Net::HTTP - t/rt-112313.t",
"X-Foo": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
ok 15 - ok for n 1635 -> response length 2045
{
"headers": {
"Connection": "close",
"Host": "httpbin.org",
"User-Agent": "Net::HTTP - t/rt-112313.t",
"X-Foo": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
ok 16 - ok for n 1636 -> response length 2046
ok 17 - reponse length increased by 1
{
"headers": {
"Connection": "close",
"Host": "httpbin.org",
"User-Agent": "Net::HTTP - t/rt-112313.t",
"X-Foo": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
ok 18 - ok for n 1637 -> response length 2047
ok 19 - reponse length increased by 1
{
"headers": {
"Connection": "close",
"Host": "httpbin.org",
"User-Agent": "Net::HTTP - t/rt-112313.t",
"X-Foo": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
ok 20 - ok for n 1638 -> response length 2048
ok 21 - reponse length increased by 1
{
"headers": {
"Connection": "close",
"Host": "httpbin.org",
"User-Agent": "Net::HTTP - t/rt-112313.t",
"X-Foo": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
ok 22 - ok for n 1639 -> response length 2049
ok 23 - reponse length increased by 1
{
"headers": {
"Connection": "close",
"Host": "httpbin.org",
"User-Agent": "Net::HTTP - t/rt-112313.t",
"X-Foo": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
ok 24 - ok for n 1640 -> response length 2050
ok 25 - reponse length increased by 1
{
"headers": {
"Connection": "close",
"Host": "httpbin.org",
"User-Agent": "Net::HTTP - t/rt-112313.t",
"X-Foo": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
ok 26 - ok for n 1641 -> response length 2051
ok 27 - reponse length increased by 1
{
"headers": {
"Connection": "close",
"Host": "httpbin.org",
"User-Agent": "Net::HTTP - t/rt-112313.t",
"X-Foo": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
ok 28 - ok for n 2659 -> response length 3069
{
"headers": {
"Connection": "close",
"Host": "httpbin.org",
"User-Agent": "Net::HTTP - t/rt-112313.t",
"X-Foo": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
ok 29 - ok for n 2660 -> response length 3070
ok 30 - reponse length increased by 1
{
"headers": {
"Connection": "close",
"Host": "httpbin.org",
"User-Agent": "Net::HTTP - t/rt-112313.t",
"X-Foo": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
ok 31 - ok for n 2661 -> response length 3071
ok 32 - reponse length increased by 1
{
"headers": {
"Connection": "close",
"Host": "httpbin.org",
"User-Agent": "Net::HTTP - t/rt-112313.t",
"X-Foo": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
ok 33 - ok for n 2662 -> response length 3072
ok 34 - reponse length increased by 1
{
"headers": {
"Connection": "close",
"Host": "httpbin.org",
"User-Agent": "Net::HTTP - t/rt-112313.t",
"X-Foo": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
ok 35 - ok for n 2663 -> response length 3073
ok 36 - reponse length increased by 1
not ok 37 - ok for n 2664 -> response length -1
# Failed test 'ok for n 2664 -> response length -1'
# at t/rt-112313.t line 111.
# error: timeout at t/rt-112313.t line 92.
not ok 38 - reponse length increased by 1
# Failed test 'reponse length increased by 1'
# at t/rt-112313.t line 115.
# got: '-3074'
# expected: '1'
{
"headers": {
"Connection": "close",
"Host": "httpbin.org",
"User-Agent": "Net::HTTP - t/rt-112313.t",
"X-Foo": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
ok 39 - ok for n 2665 -> response length 3075
not ok 40 - reponse length increased by 1
# Failed test 'reponse length increased by 1'
# at t/rt-112313.t line 115.
# got: '3076'
# expected: '1'
1..40
# Looks like you failed 3 tests of 40.
I added some more debug and it looks like when this happens this doesn't even reach the read_entity_body loop, meaning this is probably just a boring old slow connection problem.
I can't reproduce it at all with the timeout being 60; On the other hand it's possible to always reproduce this by setting the timeout to 1.
The test might need to be more defensive and not die so badly just because of the timeout.
Net::HTTP::NB blocks on connect()
Saw this in an strace:
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3<TCP:[4870277]>
ioctl(3<TCP:[4870277]>, TCGETS, 0x7ea8924c) = -1 ENOTTY (Inappropriate ioctl for
device)
_llseek(3<TCP:[4870277]>, 0, 0x7ea892a8, SEEK_CUR) = -1 ESPIPE (Illegal seek)
ioctl(3<TCP:[4870277]>, TCGETS, 0x7ea8924c) = -1 ENOTTY (Inappropriate ioctl for
device)
_llseek(3<TCP:[4870277]>, 0, 0x7ea892a8, SEEK_CUR) = -1 ESPIPE (Illegal seek)
fcntl64(3<TCP:[4870277]>, F_SETFD, FD_CLOEXEC) = 0
connect(3<TCP:[4870277]>, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_
addr("208.74.123.84")}, 16) = 0
This comes from just calling:
my $s = Net::HTTP::NB->new(
Host => 'cpanel.net',
Blocking => 0,
) or die;
Is this a bug, or a known part of the design? Is there any way to get a non-blocking connect()?
Stop using httpbin for live tests
Using HTTP proxy hangs [rt.cpan.org #81099]
Migrated from rt.cpan.org#81099 (status was 'new')
Requestors:
From [email protected] on 2012-11-10 21:42:51:
When using an HTTP proxy on versions 6.04 and 6.05, the query does does not
always respect the timeout and will hang indefinitely. When I revert to version
6.03, the problem disappears.
during a https-request the READ TIMEOUT not workunder win32 [rt.cpan.org #3316]
Migrated from rt.cpan.org#3316 (status was 'open')
Requestors:
From on 2003-08-22 12:59:14:
my $ua = new LWP::UserAgent;
# set read timeout
$ua->timeout(3);
...
my $result = $ua->request(...);
on an http-request the timeout works
on an https-request the timeout NOT works
From on 2004-06-12 05:27:49:
[guest - Fri Aug 22 08:59:14 2003]:
> my $ua = new LWP::UserAgent;
>
> # set read timeout
> $ua->timeout(3);
> ...
> my $result = $ua->request(...);
>
> on an http-request the timeout works
> on an https-request the timeout NOT works
I've noticed the same problem, under Fedora 1 (up2date to June 2004),
with the latest (5.79) libwww installed.
I'm not 100% certain, but I think this problem is not limited to https,
but instead to persistent connections and servers that send incorrect
Content-Length headers. This could do with some more investigation though.
I've tracked the problem down to LWP::Protocol::http::SocketMethods, in
the sysread() method. The code in question is this:
if (my $timeout = ${*$self}{io_socket_timeout}) {
die "read timeout" unless $self->can_read($timeout);
}
else {
...
I can't find any mention of {io_socket_timeout} anywhere in the LWP
module. As a result, I don't think timeouts are ever actually used
correctly. I kludged a solution by prefixing the above code with:
${*$self}{io_socket_timeout}=180;
...and found that https downloads are now considerably more reliable,
and (I think) have stopped hanging. I never could find a specific site
that repeatably caused a problem, so it's hard for me to provide a
testcase though.
I hope that helps - it took me a while to track down, so hopefully I've
saved someone else the trouble ;-)
...Ralph Bolton
http://www.coofercat.com/
From on 2004-06-13 12:16:29:
[guest - Sat Jun 12 01:27:49 2004]:
> ${*$self}{io_socket_timeout}=180;
>
> ...and found that https downloads are now considerably more reliable,
> and (I think) have stopped hanging. I never could find a specific site
> that repeatably caused a problem, so it's hard for me to provide a
> testcase though.
Sorry, I was jumping the gun somewhat... This doesn't fix the problem at
all.
I'm finding my process sitting in a blocking read() of a socket
connected to a remote server on port 443 (via strace and lsof). This
leads me to think that the socket is not non-blocking. The call to
nonblock() is in an eval{} block, so I wonder if it's somehow failing...?
From on 2006-01-06 13:41:22:
Running under mod perl 2 undef red hat and debian making connection to
remote server over ssl with timeout of 10:
The apache process exits and puts this in the error log:
[Fri Jan 06 11:59:52 2006] [notice] child pid 5140 exit signal Alarm
clock (14)
I assume this is the same bug.
Tom
From [email protected] on 2006-03-08 19:09:49:
I'm experiencing the same problems using libwww-perl-5.805 with Perl
5.8.4 under Debian/Sarge and Perl 5.8.8 under SuSE Linux 10.0 when
trying to connect to a server that does not respond to HTTPS requests, e.g.:
| $ time perl -MLWP::UserAgent -e
'(my$ua=LWP::UserAgent->new)->timeout(3);print$ua->simple_request(HTTP::Request->new(GET=>"https://62.128.1.1/"))->as_string'
500 Connect failed: connect: Die Wartezeit fรยผr die Verbindung ist
abgelaufen; Die Wartezeit fรยผr die Verbindung ist abgelaufen
| Content-Type: text/plain
| Client-Date: Wed, 08 Mar 2006 19:00:52 GMT
| Client-Warning: Internal response
|
| 500 Connect failed: connect: Connection timed out; Connection timed out
|
| real 3m9.150s
| user 0m0.124s
| sys 0m0.024s
So the timeout occurs not until a few minutes later, when the OS' TCP
stack gives up, but not because I've set a timeout.
However, it works just fine for HTTP:
| $ time perl -MLWP::UserAgent -e
'(my$ua=LWP::UserAgent->new)->timeout(3);print$ua->simple_request(HTTP::Request->new(GET=>"http://62.128.1.1/"))->as_string'
| 500 Can't connect to 62.128.1.1:80 (connect: timeout)
| Content-Type: text/plain
| Client-Date: Wed, 08 Mar 2006 18:58:05 GMT
| Client-Warning: Internal response
|
| 500 Can't connect to 62.128.1.1:80 (connect: timeout)
|
| real 0m3.128s
| user 0m0.092s
| sys 0m0.020s
fany.
From [email protected] on 2006-03-08 19:54:56:
The difference between HTTP and HTTPS can also be observed using strace:
For HTTP, the socket is set to O_NONBLOCK, and then select() is
used to catch the timeout:
$ strace -t perl -MLWP::UserAgent -e
'(my$ua=LWP::UserAgent->new)->timeout(3);$ua->simple_request(HTTP::Request->new(GET=>"http://62.128.1.1/"))'
[...]
20:46:34 socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
20:46:34 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbff0b4e8) = -1 EINVAL
(Invalid argument)
20:46:34 _llseek(3, 0, 0xbff0b530, SEEK_CUR) = -1 ESPIPE (Illegal seek)
20:46:34 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbff0b4e8) = -1 EINVAL
(Invalid argument)
20:46:34 _llseek(3, 0, 0xbff0b530, SEEK_CUR) = -1 ESPIPE (Illegal seek)
20:46:34 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
20:46:34 fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
20:46:34 fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
20:46:34 connect(3, {sa_family=AF_INET, sin_port=htons(80),
sin_addr=inet_addr("62.128.1.1")}, 16) = -1 EINPROGRESS (Operation now
in progress)
20:46:34
stat64("/usr/local/lib/perl5/5.8.8/i686-linux-64int-ld/IO/Select.pmc",
0xbff0b56c) = -1 ENOENT (No such file or directory)
20:46:34
stat64("/usr/local/lib/perl5/5.8.8/i686-linux-64int-ld/IO/Select.pm",
{st_mode=S_IFREG|0444, st_size=8021, ...}) = 0
20:46:34
open("/usr/local/lib/perl5/5.8.8/i686-linux-64int-ld/IO/Select.pm",
O_RDONLY|O_LARGEFILE) = 4
20:46:34 ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbff0b2a8) = -1 ENOTTY
(Inappropriate ioctl for device)
20:46:34 _llseek(4, 0, [0], SEEK_CUR) = 0
20:46:34 read(4, "# IO::Select.pm\n#\n# Copyright (c"..., 4096) = 4096
20:46:34 _llseek(4, 4029, [4029], SEEK_SET) = 0
20:46:34 _llseek(4, 0, [4029], SEEK_CUR) = 0
20:46:34 close(4) = 0
20:46:34 select(8, NULL, [3], NULL, {3, 0}) = 0 (Timeout)
For HTTPS, however, O_NONBLOCK does not get set,
which causes the connect() to hang:
$ strace -t perl -MLWP::UserAgent -e
'(my$ua=LWP::UserAgent->new)->timeout(3);$ua->simple_request(HTTP::Request->new(GET=>"https://62.128.1.1/"))'
[...]
20:47:45 socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
20:47:45 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfae2c28) = -1 EINVAL
(Invalid argument)
20:47:45 _llseek(3, 0, 0xbfae2c70, SEEK_CUR) = -1 ESPIPE (Illegal seek)
20:47:45 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfae2c28) = -1 EINVAL
(Invalid argument)
20:47:45 _llseek(3, 0, 0xbfae2c70, SEEK_CUR) = -1 ESPIPE (Illegal seek)
20:47:45 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
20:47:45 connect(3, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr("62.128.1.1")}, 16) = -1 ETIMEDOUT (Connection timed out)
20:50:54 brk(0x844e000) = 0x844e000
fany.
From [email protected] on 2006-04-04 16:25:09:
I've narrowed this down further using the debugger:
The cause of this problem is the following method within Net::HTTPS
(version 1.00):
60 # The underlying SSLeay classes fails to work if the socket is
61 # placed in non-blocking mode. This override of the blocking
62 # method makes sure it stays the way it was created.
63 sub blocking { } # noop
Indeed, I get strange results when trying to circumvent this:
| fany@ray:~> perl -MNet::HTTPS -MLWP::UserAgent -le '{ package
Net::HTTPS; sub blocking { shift->SUPER::blocking(@_) } }
(my$ua=LWP::UserAgent->new)->timeout(3);print
$ua->simple_request(HTTP::Request->new(GET=>"https://www.noris.net/"))->as_string'
| 500 read failed:
| Content-Type: text/plain
| Client-Date: Tue, 04 Apr 2006 16:15:47 GMT
| Client-Warning: Internal response
|
| 500 read failed:
|
I think I'll give up now.
Here's my current workaround BTW:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
package my::LWP::UserAgent;
use base 'LWP::UserAgent';
sub simple_request {
my $self = shift;
my ($request) = @_;
return $self->SUPER::simple_request(@_)
unless $request->uri =~ /^https:/ &&
( my $timeout = $self->timeout );
my $response;
eval {
local $SIG{ALRM} = sub { die "TIMEOUT\n" };
alarm $timeout;
$response = $self->SUPER::simple_request(@_);
alarm 0;
};
$response;
}
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Regards,
fany
From on 2006-06-15 07:52:24:
<a href='http://www.yahoo.com'></a>Thanks! http://www.ringtones-dir.com/download/ <a href='http://www.ringtones-dir.com'>download ringtones</a>. <a href="http://www.ringtones-dir.com ">nokia ringtones</a>: ringtones site, Free nokia ringtones here, Download ringtones FREE. Also [url]http://www.ringtones-dir.com/free/[/url] and [link=http://www.ringtones-dir.com]ring tones[/link] From site .
From on 2006-06-15 07:52:50:
Incorrect example of Net::HTTP::NB usage [rt.cpan.org #107770]
Migrated from rt.cpan.org#107770 (status was 'new')
Requestors:
From [email protected] on 2015-10-14 10:15:16:
In SYNOPSIS section we can see an example of how you can send request and read response with Net::HTTP::NB. But this example has potential problems. Let's see this test server:
use strict;
use IO::Socket;
my $serv = IO::Socket::INET->new(Listen => 10, LocalPort => 8080)
or die $@;
my $body = 'This is the body';
my $header = join(
"\r\n",
"HTTP/1.1 200 OK",
"Server: nginx/1.0.4",
"Date: Thu, 06 Oct 2011 16:14:01 GMT",
"Content-Type: text/html",
"Content-Length: ".length($body),
"Connection: keep-alive",
"Vary: Accept-Encoding",
"X-Powered-By: PHP/5.3.6",
"\r\n"
);
while (warn("waiting for next request...\n") and my $client = $serv->accept()) {
my $req;
while ($req !~ /\r\n\r\n$/) {
$client->sysread($req, 1024, length $req) or die $!;
}
$client->syswrite($header.$body);
<$client>; # keep-alive ;)
}
__END__
And this client (a little reworked example from SYNOPSIS):
use strict;
use Net::HTTP::NB;
my $s = Net::HTTP::NB->new(Host => "localhost:8080") || die $@;
$s->write_request(GET => "/", 'User-Agent' => "Mozilla/5.0");
use IO::Select;
my $sel = IO::Select->new($s);
READ_HEADER: {
die "Header timeout" unless $sel->can_read(10);
my($code, $mess, %h) = $s->read_response_headers;
redo READ_HEADER unless $code;
}
while (1) {
die "Body timeout" unless $sel->can_read(10);
my $buf;
my $n = $s->read_entity_body($buf, 1024);
last unless $n;
print $buf;
}
__END__
And output of this client will be "Body timeout" error, instead of expected "This is the body" body content.
The problem is that Net::HTTP::Methods internally uses a buffer when reading data from the server. Here read_response_headers() call readed both headers and data, returned headers for us and stored body in the buffer. So, body now in the buffer instead of a socket and socket will not be available for read anymore (until server will close connection, but our uses keep-alive, so will not do it). This is why our can_read(10) call timed out after 10 seconds.
And this is how this example may looks like to work properly:
use strict;
use Net::HTTP::NB;
use Errno qw/EAGAIN EWOULDBLOCK/;
my $s = Net::HTTP::NB->new(Host => "localhost:8080", KeepAlive => 1) || die $@;
$s->write_request(GET => "/", 'User-Agent' => "Mozilla/5.0");
use IO::Select;
my $sel = IO::Select->new($s);
READ_HEADER: {
die "Header timeout" unless $sel->can_read(10);
my($code, $mess, %h) = $s->read_response_headers;
redo READ_HEADER unless $code;
}
# Net::HTTP::NB uses internal buffer, so we should check it before
# socket check by calling read_entity_body()
# make socket non-blocking, so read_entity_body() will not block
$s->blocking(0);
while (1) {
my $buf;
my $n;
# try to read until error or all data received
while (1) {
my $tmp_buf;
$n = $s->read_entity_body($tmp_buf, 1024);
if ($n == -1 || (!defined($n) && ($! == EWOULDBLOCK || $! == EAGAIN))) {
last; # no data available this time
}
elsif ($n) {
$buf .= $tmp_buf; # data received
}
elsif (defined $n) {
last; # $n == 0, all readed
}
else {
die "Read error occured: ", $!; # $n == undef
}
}
print $buf if length $buf;
last if defined $n && $n == 0; # all readed
die "Body timeout" unless $sel->can_read(10); # wait for new data
}
__END__
The bad news is that most modules which uses Net::HTTP::NB doing it wrong, as showed in the example from the documentation.
die creates new warning on missing newline
Got this report via email:
Using Net::HTTP::Methods I very often receive errors:
Use of uninitialized value $line in concatenation (.) or string at /opt/perl5.28.2/lib/site_perl/5.28.2/Net/HTTP/Methods.pm line 534.
Use of uninitialized value $line in concatenation (.) or string at /opt/perl5.28.2/lib/site_perl/5.28.2/Net/HTTP/Methods.pm line 534.
die "Missing newline after chunk data: '$line'"
if !defined($line) || $line ne "";
When $line is undefined it tried to print it in die statement.
Passing the '--live-tests' option to 'perl Makefile.PL' does not DWIM [rt.cpan.org #120779]
Migrated from rt.cpan.org#120779 (status was 'open')
Requestors:
From [email protected] on 2017-03-28 19:22:20
:
It appears that passing the '--live-tests' option to Net-HTTP's 'perl Makefile.PL' does not, in and of itself, cause live tests to be run. You have to manually create a 't/LIVE_TESTS' file for options to be run -- and if you do so the '--live-tests' switch is irrelevant.
I started by cloning the github repository. (I'll omit output that's not relevant.)
[gitwork] 503 $ git clone [email protected]:libwww-perl/Net-HTTP.git
Cloning into 'Net-HTTP'...
...
[gitwork] 505 $ cd Net-HTTP/
[Net-HTTP] 506 $ perl Makefile.PL && make && make test
...
PERL_DL_NONLAZY=1 "/home/jkeenan/perl5/perlbrew/perls/perl-5.24.1/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/http-nb.t ..... ok
t/http.t ........ ok
t/live-https.t .. skipped: Live tests disabled; pass --live-tests to Makefile.PL to enable
t/live.t ........ skipped: Live tests disabled; pass --live-tests to Makefile.PL to enable
t/rt-112313.t ... skipped: Live tests disabled; pass --live-tests to Makefile.PL to enable
All tests successful.
Files=5, Tests=51, 1 wallclock secs ( 0.03 usr 0.00 sys + 0.16 cusr 0.01 csys = 0.20 CPU)
Result: PASS
#####
Oops! Let me clean and rerun Makefile.PL with that switch.
#####
[Net-HTTP] 507 $ make clean
...
[Net-HTTP] 508 $ perl Makefile.PL --live-tests
...
[Net-HTTP] 509 $ make
...
[Net-HTTP] 510 $ make test
PERL_DL_NONLAZY=1 "/home/jkeenan/perl5/perlbrew/perls/perl-5.24.1/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/http-nb.t ..... ok
t/http.t ........ ok
t/live-https.t .. skipped: Live tests disabled; pass --live-tests to Makefile.PL to enable
t/live.t ........ skipped: Live tests disabled; pass --live-tests to Makefile.PL to enable
t/rt-112313.t ... skipped: Live tests disabled; pass --live-tests to Makefile.PL to enable
All tests successful.
Files=5, Tests=51, 0 wallclock secs ( 0.02 usr 0.01 sys + 0.14 cusr 0.02 csys = 0.19 CPU)
Result: PASS
#####
What? Still no live tests. So I peer into the failing tests.
#####
$ ack -C2 'live-tests' t
t/live-https.t
1-BEGIN {
2- unless ( -f "t/LIVE_TESTS" || -f "LIVE_TESTS" ) {
3: print "1..0 # SKIP Live tests disabled; pass --live-tests to Makefile.PL to enable\n";
4- exit;
5- }
t/rt-112313.t
18-unless (-f "t/LIVE_TESTS" || -f "LIVE_TESTS")
19-{
20: print "1..0 # SKIP Live tests disabled; pass --live-tests to Makefile.PL to enable\n";
21- exit;
22-}
t/live.t
1-BEGIN {
2- unless ( -f "t/LIVE_TESTS" || -f "LIVE_TESTS" ) {
3: print "1..0 # SKIP Live tests disabled; pass --live-tests to Makefile.PL to enable\n";
4- exit;
5- }
#####
Does LIVE_TESTS exist? No!
#####
[Net-HTTP] 519 $ find . -type f -name 'LIVE_TESTS'
[Net-HTTP] 520 $
#####
But, if I *manually* touch t/LIVE_TESTS and repeat the other steps, I *do* get live tests.
#####
[Net-HTTP] 528 $ touch t/LIVE_TESTS
# Note absence of '--live-tests' in command below:
[Net-HTTP] 529 $ perl Makefile.PL && make && make test
...
PERL_DL_NONLAZY=1 "/home/jkeenan/perl5/perlbrew/perls/perl-5.24.1/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/http-nb.t ..... ok
t/http.t ........ ok
t/live-https.t .. ok
t/live.t ........ ok
t/rt-112313.t ... ok
All tests successful.
Files=5, Tests=103, 26 wallclock secs ( 0.04 usr 0.00 sys + 0.42 cusr 0.03 csys = 0.49 CPU)
Result: PASS
[Net-HTTP] 530 $ prove -vb t/live.t
t/live.t ..
1..6
# ----------------------------
# 200 OK
# Accept-Ranges: none
# Cache-Control: private, max-age=0
# Content-Type: text/html; charset=UTF-8
# Date: Tue, 28 Mar 2017 19:16:45 GMT
# Expires: -1
# P3P: CP="This is not a P3P policy! See https://www.google.com/support/accounts/answer/151657?hl=en for more info."
# Server: gws
# Set-Cookie: NID=100=Xz5ZEZXMBO9yQx5gCcFHsQZCR6J4lraXP6iBS83-YeyBlSyM0Z9uEwMftpumzUyKz75v4bEex6CY3OW8-lWyfWZKrUBeW1W_ZWDqRyAx9BR_Bqh8TFhBdRHNL9dAQyBZYdhbNaKGQI6BQYFP; expires=Wed, 27-Sep-2017 19:16:45 GMT; path=/; domain=.google.com; HttpOnly
# Transfer-Encoding: chunked
# Vary: Accept-Encoding
# X-Frame-Options: SAMEORIGIN
# X-XSS-Protection: 1; mode=block
#
ok 1
ok 2
ok 3
# ----------------------------
# 200 OK
# Accept-Ranges: none
# Cache-Control: private, max-age=0
# Content-Type: text/html; charset=UTF-8
# Date: Tue, 28 Mar 2017 19:16:45 GMT
# Expires: -1
# P3P: CP="This is not a P3P policy! See https://www.google.com/support/accounts/answer/151657?hl=en for more info."
# Server: gws
# Set-Cookie: NID=100=YP0B1nfutl7Hs9nRzx3mMyyOLWalljomO_dwBkYRHFDJI2oEfiGtPM4NaktLoWC9NmANW3MPMygtj69gNYZrhCxsi_mkq_EJfMmcykBjZ4bzH-BMS_Vh4BZwxaUdtWzUKP4TUopbAmKv3WUM; expires=Wed, 27-Sep-2017 19:16:46 GMT; path=/; domain=.google.com; HttpOnly
# Transfer-Encoding: chunked
# Vary: Accept-Encoding
# X-Frame-Options: SAMEORIGIN
# X-XSS-Protection: 1; mode=block
#
ok 4
ok 5
ok 6
ok
All tests successful.
Files=1, Tests=6, 1 wallclock secs ( 0.01 usr 0.01 sys + 0.07 cusr 0.01 csys = 0.10 CPU)
Result: PASS
#####
Hence, there is a defect in Makefile.PL.
Thank you very much.
Jim Keenan
From [email protected] on 2017-03-28 19:44:36
:
On 2017-03-28 12:22:20, JKEENAN wrote:
> It appears that passing the '--live-tests' option to Net-HTTP's 'perl
> Makefile.PL' does not, in and of itself, cause live tests to be run.
it works for me:
I added to Makefile.PL:
use Data::Dumper;
print STDERR Dumper(\%opt);
and then:
: [ether@jaeger git/Net-HTTP]$; perl Makefile.PL --live-tests
$VAR1 = {
'live-tests' => 1
};
Generating a Unix-style Makefile
Writing Makefile for Net::HTTP
Writing MYMETA.yml and MYMETA.json
: [ether@jaeger git/Net-HTTP]$;
: [ether@jaeger git/Net-HTTP]$; ls -l t
total 40
-rw-r--r-- 1 ether staff 0 28 Mar 12:42 LIVE_TESTS
-rw-r--r-- 1 ether staff 1598 11 Mar 2016 apache-https.t
-rw-r--r-- 1 ether staff 1428 11 Mar 2016 apache.t
-rw-r--r-- 1 ether staff 1489 29 Jun 2015 http-nb.t
-rw-r--r-- 1 ether staff 5917 29 Jun 2015 http.t
> You have to manually create a 't/LIVE_TESTS' file for options to be
> run -- and if you do so the '--live-tests' switch is irrelevant.
The Makefile.PL creates this directory if the --live-tests option was used.
From [email protected] on 2017-03-28 19:47:02
:
On Tue Mar 28 15:44:36 2017, ETHER wrote:
> On 2017-03-28 12:22:20, JKEENAN wrote:
> > It appears that passing the '--live-tests' option to Net-HTTP's 'perl
> > Makefile.PL' does not, in and of itself, cause live tests to be run.
>
> it works for me:
>
> I added to Makefile.PL:
>
> use Data::Dumper;
> print STDERR Dumper(\%opt);
>
> and then:
>
> : [ether@jaeger git/Net-HTTP]$; perl Makefile.PL --live-tests
> $VAR1 = {
> 'live-tests' => 1
> };
> Generating a Unix-style Makefile
> Writing Makefile for Net::HTTP
> Writing MYMETA.yml and MYMETA.json
> : [ether@jaeger git/Net-HTTP]$;
> : [ether@jaeger git/Net-HTTP]$; ls -l t
> total 40
> -rw-r--r-- 1 ether staff 0 28 Mar 12:42 LIVE_TESTS
> -rw-r--r-- 1 ether staff 1598 11 Mar 2016 apache-https.t
> -rw-r--r-- 1 ether staff 1428 11 Mar 2016 apache.t
> -rw-r--r-- 1 ether staff 1489 29 Jun 2015 http-nb.t
> -rw-r--r-- 1 ether staff 5917 29 Jun 2015 http.t
>
>
> > You have to manually create a 't/LIVE_TESTS' file for options to be
> > run -- and if you do so the '--live-tests' switch is irrelevant.
>
> The Makefile.PL creates this directory if the --live-tests option was used.
Hi Jim,
Thanks for looking into this. There's some conversation around it here: https://github.com/libwww-perl/Net-HTTP/pull/20 I think we do need to rework how we do this.
Best,
Olaf
Net::HTTP does not allow buffer size to be overridden in subclass [rt.cpan.org #25069]
Migrated from rt.cpan.org#25069 (status was 'open')
Requestors:
From [email protected] on 2007-02-21 22:00:19:
In Net::HTTP, read_response_headers() uses the function my_readline() to do it's dirty-work.
Under the hood, my_readline() calls sysread() with a HARD-CODED size of 1024. Ideally, this
should be an option, or otherwise parameterized. Alternately, it would make sense to
replace my_readline() in a subclass, but this is impossible since it is called as a function. One
would need to replace read_response_headers() entirely in a subclass if one wanted to
change the behavior here (to capture a larger buffer in the first read, cutting down on
latency.) Alternately, one could redefine the my_readline() function. The last two options are
terrible designs, since they involve cloning the existing code and replacing only a small bit,
and may result in future incompatibilities.
my $n = $self->sysread($_, 1024, length);
I suggest you expose or otherwise parameterize this currently hard-coded value.
Here is my current (nasty) workaround in a subclass:
package MyNetHTTP;
use base 'Net::HTTP';
sub my_sysread {
my $self = shift;
$_[1] = $READ_BUFFER_LENGTH;
$self->SUPER::sysread(@_);
}
sub read_response_headers {
my $self = shift;
local *sysread = *my_sysread;
$self->SUPER::read_response_headers( @_ );
}
From [email protected] on 2017-01-25 21:40:44:
migrated queues: libwww-perl -> Net-HTTP
Net-HTTP 6.06 intermittent death in Net::HTTP::Methods sub my_readline() (solved) [rt.cpan.org #86448]
Migrated from rt.cpan.org#86448 (status was 'new')
Requestors:
From [email protected] on 2013-06-26 15:46:52:
Description:
Net::HTTP::Methods from Net-HTTP 6.06 dies intermittently with:
Status read failed: No such file or directory at รข๏ฟฝยฆ/perl/vendor/lib/Net/HTTP/Methods.pm line 265.
Cause:
IO::Socket::SSL object can reject the read request with an error of either "SSL wants a read first" or "SSL wants a write first." This is apparently some overhead of SSL where it wants a read/write before allowing you to read/write in some cases. It's described somewhat (but not much) better under errstr() in the latest IO::Socket::SSL perldoc.
Reproducing:
I'm not sure how hard this is to reproduce since triggers are unknown. I'm accessing cloud based SOAP via SOAP::WSDL over https from a busy server and it occurs maybe one out of a dozen times. It seems to correlate with SSL taking an extra bit of time to setup the connection when something in the chain is busier or has a little latency. Thus far, I've only seen SSL_WANT_READ, and it clears immediately on the next redo READ, but there seems to be no harm in preparing for SSL_WANT_WRITE in the patch as well.
Patch:
--- broken/Net/HTTP/Methods.pm 2013-03-10 23:35:42.000000000 -0500
+++ fixed/Net/HTTP/Methods.pm 2013-06-26 10:12:37.205639200 -0500
@@ -243,40 +243,41 @@
sub my_readline {
my $self = shift;
my $what = shift;
for (${*$self}{'http_buf'}) {
my $max_line_length = ${*$self}{'http_max_line_length'};
my $pos;
while (1) {
# find line ending
$pos = index($_, "\012");
last if $pos >= 0;
die "$what line too long (limit is $max_line_length)"
if $max_line_length && length($_) > $max_line_length;
# need to read more data to find a line ending
READ:
{
die "read timeout" unless $self->can_read;
my $n = $self->sysread($_, 1024, length);
unless (defined $n) {
redo READ if $!{EINTR} || $!{EAGAIN};
+ redo READ if ( $self->isa('IO::Socket::SSL') && $self->errstr() =~ /^SSL wants a (?:read|write) first$/ );
# if we have already accumulated some data let's at least
# return that as a line
die "$what read failed: $!" unless length;
}
unless ($n) {
return undef unless length;
return substr($_, 0, length, "");
}
}
}
die "$what line too long ($pos; limit is $max_line_length)"
if $max_line_length && $pos > $max_line_length;
my $line = substr($_, 0, $pos+1, "");
$line =~ s/(\015?\012)\z// || die "Assert";
return wantarray ? ($line, $1) : $line;
}
}
Thanks for your time and your code.
--
Raymond Ferguson
Integrated Applications Engineer | CDW
Failing Net::HTTP Installation in Perl 5.32.0
I am unable to install Net::HTTP on a CentOS 6 machine in Perl 5.32.0 and I am not sure where to continue. I have installed several packages via yum in an attempt to satisfy potentially missing dependencies but nothing so far has worked. Below is my CPAN output for the install Net::HTTP command. I need this dependency installed so that I can proceed with BioPerl for Maker.
CPAN error output
cpan[1]> install Net::HTTP
Reading '/panfs/biopan03/apps/perl/perl-5.32.0_cpan/cpan/2.28/Metadata'
Database was generated on Mon, 08 Feb 2021 11:41:03 GMT
Running install for module 'Net::HTTP'
CPAN: Module::Signature security checks disabled because Module::Signature
not installed. Please consider installing the Module::Signature module.
You may also need to be able to connect over the Internet to the public
key servers like pool.sks-keyservers.net or pgp.mit.edu.
Checksum for /panfs/biopan03/apps/perl/perl-5.32.0_cpan/cpan/2.28/sources/authors/id/O/OA/OALDERS/Net-HTTP-6.20.tar.gz ok
Scanning cache /panfs/biopan03/apps/perl/perl-5.32.0_cpan/cpan/2.28/build for sizes
............................................................................DONE
Configuring O/OA/OALDERS/Net-HTTP-6.20.tar.gz with Makefile.PL
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Net::HTTP
Writing MYMETA.yml and MYMETA.json
OALDERS/Net-HTTP-6.20.tar.gz
/panfs/biopan03/apps/perl/5.32.0_cpan/perl Makefile.PL -- OK
Running make for O/OA/OALDERS/Net-HTTP-6.20.tar.gz
cp lib/Net/HTTP.pm blib/lib/Net/HTTP.pm
cp lib/Net/HTTP/NB.pm blib/lib/Net/HTTP/NB.pm
cp lib/Net/HTTP/Methods.pm blib/lib/Net/HTTP/Methods.pm
cp lib/Net/HTTPS.pm blib/lib/Net/HTTPS.pm
Manifying 4 pod documents
OALDERS/Net-HTTP-6.20.tar.gz
/usr/bin/make -- OK
The current configuration of allow_installing_outdated_dists is 'ask/no', but for this option we would need 'CPAN::DistnameInfo' installed. Please install 'CPAN::DistnameInfo' as soon as possible. As long as we are not equipped with 'CPAN::DistnameInfo' this option does not take effect
Running make test for OALDERS/Net-HTTP-6.20.tar.gz
PERL_DL_NONLAZY=1 "/panfs/biopan03/apps/perl/5.32.0_cpan/perl" "-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.44
#
# === Configure Suggests ===
#
# Module Want Have
# -------- ------- ----
# JSON::PP 2.27300 4.04
#
# === Build Requires ===
#
# Module Want Have
# ------------------- ---- ----
# ExtUtils::MakeMaker any 7.44
#
# === Test Requires ===
#
# Module Want Have
# ------------------- ---- --------
# Data::Dumper any 2.174
# ExtUtils::MakeMaker any 7.44
# File::Spec any 3.78
# IO::Select any 1.42
# Socket any 2.029
# Test::More any 1.302175
#
# === Test Recommends ===
#
# Module Want Have
# ---------- -------- --------
# CPAN::Meta 2.120900 2.150010
#
# === Runtime Requires ===
#
# Module Want Have
# ---------------------- ---- -----
# Carp any 1.50
# Compress::Raw::Zlib any 2.093
# IO::Socket::INET any 1.41
# IO::Uncompress::Gunzip any 2.093
# URI any 5.05
# base any 2.27
# strict any 1.11
# warnings any 1.47
#
# === Runtime Suggests ===
#
# Module Want Have
# ----------------- ----- -----
# IO::Socket any 1.43
# IO::Socket::INET6 any 2.72
# IO::Socket::IP any 0.39
# IO::Socket::SSL 2.012 2.069
# Symbol any 1.08
#
t/00-report-prereqs.t .. ok
t/http-nb.t ............ ok
t/http.t ............... ok
t/live-https.t ......... skipped: Can't connect to www.cpan.org:443
t/live.t ............... 1/6 Use of uninitialized value $buf in substitution (s///) at t/live.t line 59.
# Failed test at t/live.t line 62.
# undef
# doesn'
t match
'(?^:text/html)'
# Failed test at t/live.t line 63.
# undef
# doesn't match '(?^i:</html>)'
Server closed connection without sending any data back at /panfs/biopan03/apps/perl/perl-5.32.0_cpan/cpan/2.28/build/Net-HTTP-6.20-12/blib/lib/Net/HTTP/Methods.pm line 391.
# Looks like your test exited with 255 just after 3.
t/live.t ............... Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 5/6 subtests
t/socket-class.t ....... ok
Test Summary Report
-------------------
t/live.t (Wstat: 65280 Tests: 3 Failed: 2)
Failed tests: 2-3
Non-zero exit status: 255
Parse errors: Bad plan. You planned 6 tests but ran 3.
Files=6, Tests=59, 1 wallclock secs ( 0.04 usr 0.01 sys + 0.74 cusr 0.20 csys = 0.99 CPU)
Result: FAIL
Failed 1/6 test programs. 2/59 subtests failed.
make: *** [test_dynamic] Error 255
Lockfile removed.
OALDERS/Net-HTTP-6.20.tar.gz
/usr/bin/make test -- NOT OK
//hint// to see the cpan-testers results for installing this module, try:
reports OALDERS/Net-HTTP-6.20.tar.gz
Failed during this command:
OALDERS/Net-HTTP-6.20.tar.gz : make_test NOI suspected that my proxy was getting in the way of this install but even after changing CPAN's proxy settings, I am still unable to install the module. The environment variables for http_proxy and https_proxy are set correctly and all applications are able to reach out to their servers, as evidenced by CPAN's ability to get the tarballs for these installs. This is the only module that is failing for me.
What am I missing to get this module installed? Thanks so much for your support.
Failing with Net::HTTP [rt.cpan.org #72790]
Migrated from rt.cpan.org#72790 (status was 'open')
Requestors:
From [email protected] on 2011-11-28 23:22:03:
Ref - RT#72580
"I just removed it in commit 208a2e384a176237. We'll se if anybody
complains."
It seems that it breaks pretty quickly if Net::SSL is required.
Sample code:
use Net::SSL;
$ENV{PERL_NET_HTTPS_SSL_SOCKET_CLASS}="Net::SSL";
use LWP::UserAgent;
my $ua = LWP::UserAgent->new;
my $res = $ua->get('https://foo.com/bar');
read failed: at
/home/ashley/ms5_lib_20111014/lib/perl5/Net/HTTP/Methods.pm line 256
at
/home/ashley/ms5_lib_20111014/lib/perl5/i686-linux-gnu-thread-multi/Net/SSL.pm
line 211
We can't switch to IO::Socket::SSL - it doesn't handle our PKCS certs,
or our proxy.
From [email protected] on 2011-12-21 15:31:31:
We hit problem with chunked HTTPS response. GETting
<https://bugzilla.redhat.com/show_bug.cgi?id=1> results in truncated
body. Net::HTTP croak about mallformed chunk is added into headers but
no error is reported to LWP::UserAgent. Actually the response is valid
and fully parseble by Net::HTTP if carried on plain TCP. I think
IO::Socket::SSL truncates or splits the response data chunk decoder does
not expect it.
See for more details (https://bugzilla.redhat.com/show_bug.cgi?id=768394).
From [email protected] on 2012-01-03 15:52:49:
I stumbled on this bug myself.
When I took ppisar's suggestion of reverting the change in RT#72580, the
problem goes away.
I'm running perl-5.14.2, built via perlbrew on Dec 27, 2011 (with -
Dusethreads and -Dnoextensions=ODB_File) on an old CentOS 5.2 server with
module versions libwww-perl 6.02 and IO::Socket::SSL 1.53.
Let me know if I can provide any other details that would be helpful.
--
Andy
From [email protected] on 2012-01-03 19:48:23:
I've restored the blocking override for Net::SSL in <https://github.com/gisle/libwww-perl/commit/6049e9d9eb2e22693053ad2af5ddba2b6824ac66>.
IO::Socket::SSL is supposed to handle blocking correctly so I need to investigate what goes wrong in that case some more.
t/live-https.t fails with IO::Socket::SSL 1.49
$ cpanm --local-lib local-lib --reinstall Net::HTTP -v
cpanm (App::cpanminus) 1.7042 on perl 5.012004 built for darwin-thread-multi-2level
Work directory is /Users/al/.cpanm/work/1493464230.49632
You have make /usr/bin/make
You have LWP 6.03
You have /usr/bin/tar: bsdtar 2.8.3 - libarchive 2.8.3
You have /usr/bin/unzip
Searching Net::HTTP () on cpanmetadb ...
--> Working on Net::HTTP
Fetching http://www.cpan.org/authors/id/O/OA/OALDERS/Net-HTTP-6.14.tar.gz ... OK
Unpacking Net-HTTP-6.14.tar.gz
x Net-HTTP-6.14/
x Net-HTTP-6.14/Changes
x Net-HTTP-6.14/CONTRIBUTORS
x Net-HTTP-6.14/cpanfile
x Net-HTTP-6.14/dist.ini
x Net-HTTP-6.14/INSTALL
x Net-HTTP-6.14/lib/
x Net-HTTP-6.14/LICENSE
x Net-HTTP-6.14/Makefile.PL
x Net-HTTP-6.14/MANIFEST
x Net-HTTP-6.14/META.json
x Net-HTTP-6.14/META.yml
x Net-HTTP-6.14/perlcriticrc
x Net-HTTP-6.14/perltidyrc
x Net-HTTP-6.14/README.md
x Net-HTTP-6.14/t/
x Net-HTTP-6.14/tidyall.ini
x Net-HTTP-6.14/t/00-report-prereqs.dd
x Net-HTTP-6.14/t/00-report-prereqs.t
x Net-HTTP-6.14/t/http-nb.t
x Net-HTTP-6.14/t/http.t
x Net-HTTP-6.14/t/live-https.t
x Net-HTTP-6.14/t/live.t
x Net-HTTP-6.14/t/rt-112313.t
x Net-HTTP-6.14/lib/Net/
x Net-HTTP-6.14/lib/Net/HTTP/
x Net-HTTP-6.14/lib/Net/HTTP.pm
x Net-HTTP-6.14/lib/Net/HTTPS.pm
x Net-HTTP-6.14/lib/Net/HTTP/Methods.pm
x Net-HTTP-6.14/lib/Net/HTTP/NB.pm
Entering Net-HTTP-6.14
Checking configure dependencies from META.json
Checking if you have ExtUtils::MakeMaker 6.58 ... Yes (7.24)
Running Makefile.PL
Configuring Net-HTTP-6.14 ... Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Net::HTTP
Writing MYMETA.yml and MYMETA.json
OK
Checking dependencies from MYMETA.json ...
Checking if you have warnings 0 ... Yes (1.09)
Checking if you have base 0 ... Yes (2.15)
Checking if you have URI 0 ... Yes (1.59)
Checking if you have IO::Uncompress::Gunzip 0 ... Yes (2.024)
Checking if you have Data::Dumper 0 ... Yes (2.125)
Checking if you have ExtUtils::MakeMaker 0 ... Yes (7.24)
Checking if you have File::Spec 0 ... Yes (3.62)
Checking if you have IO::Socket::INET 0 ... Yes (1.31)
Checking if you have vars 0 ... Yes (1.01)
Checking if you have Compress::Raw::Zlib 0 ... Yes (2.024)
Checking if you have Carp 0 ... Yes (1.38)
Checking if you have strict 0 ... Yes (1.04)
Checking if you have Test::More 0 ... Yes (1.302078)
Checking if you have IO::Select 0 ... Yes (1.17)
Checking if you have Socket 0 ... Yes (2.020)
Building and testing Net-HTTP-6.14 ... cp lib/Net/HTTP/NB.pm blib/lib/Net/HTTP/NB.pm
cp lib/Net/HTTP.pm blib/lib/Net/HTTP.pm
cp lib/Net/HTTPS.pm blib/lib/Net/HTTPS.pm
cp lib/Net/HTTP/Methods.pm blib/lib/Net/HTTP/Methods.pm
Manifying 4 pod documents
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-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.24
#
# === Configure Suggests ===
#
# Module Want Have
# -------- ------- -------
# JSON::PP 2.27300 2.27203
#
# === Build Requires ===
#
# Module Want Have
# ------------------- ---- ----
# ExtUtils::MakeMaker any 7.24
#
# === Test Requires ===
#
# Module Want Have
# ------------------- ---- --------
# Data::Dumper any 2.125
# ExtUtils::MakeMaker any 7.24
# File::Spec any 3.62
# IO::Select any 1.17
# Socket any 2.020
# Test::More any 1.302078
#
# === Test Recommends ===
#
# Module Want Have
# ---------- -------- --------
# CPAN::Meta 2.120900 2.150005
#
# === Runtime Requires ===
#
# Module Want Have
# ---------------------- ---- -----
# Carp any 1.38
# Compress::Raw::Zlib any 2.024
# IO::Socket::INET any 1.31
# IO::Uncompress::Gunzip any 2.024
# URI any 1.59
# base any 2.15
# strict any 1.04
# vars any 1.01
# warnings any 1.09
#
# === Runtime Suggests ===
#
# Module Want Have
# ----------------- ---- ----
# IO::Socket any 1.31
# IO::Socket::INET6 any 2.67
# IO::Socket::IP any 0.37
# IO::Socket::SSL 1.38 1.49
# Symbol any 1.07
#
t/00-report-prereqs.t .. ok
t/http-nb.t ............ ok
t/http.t ............... ok
t/live-https.t ......... Net::HTTPS: SSL connect attempt failed with unknown errorerror:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version at t/live-https.t line 34.
# Looks like your test exited with 255 before it could output anything.
t/live-https.t ......... Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 6/6 subtests
t/live.t ............... ok
t/rt-112313.t .......... ok
Test Summary Report
-------------------
t/live-https.t (Wstat: 65280 Tests: 0 Failed: 0)
Non-zero exit status: 255
Parse errors: Bad plan. You planned 6 tests but ran 0.
Files=6, Tests=98, 28 wallclock secs ( 0.06 usr 0.02 sys + 0.88 cusr 0.14 csys = 1.10 CPU)
Result: FAIL
Failed 1/6 test programs. 0/98 subtests failed.
make: *** [test_dynamic] Error 255
FAIL
! Installing Net::HTTP failed. See /Users/al/.cpanm/work/1493464230.49632/build.log for details. Retry with --force to force install it.
IO::Socket::SSL is 1.49.
Upgrading to 2.048 fixed the issue. You might want to raise the dependency version.
Net:HTTP 6.05 dows not work with VMware-vSphere-Perl-SDK [rt.cpan.org #81684]
Migrated from rt.cpan.org#81684 (status was 'open')
Requestors:
Attachments:
From [email protected] on 2012-12-04 07:40:22
:
After update Net-HTTP from 6.03 to 6.05 VMware-vSphere-Perl-SDK does not
work
I get
SOAP request error - possibly a protocol issue: <?xml version="1.0"
encoding="UTF-8"?>
For 6.03 all worked fine.
I use FreeBSD 8.2-RELEASE. Not tested for another OSes.
# perl -v
This is perl 5, version 12, subversion 4 (v5.12.4) built for
i386-freebsd-64int
How-to-repeat:
e.g.
/usr/local/share/examples/vmware-vsphere-cli/performance/viperformance.pl --host
XX.XX.XX.XX --server XX.XX.XX.XX --countertype net --samples 1
--instance "*" --username root --password XXXXXXXXX
From [email protected] on 2013-04-19 15:29:39
:
seems like this issue was solved by #81237 (released with 6.0.6)
From [email protected] on 2013-09-11 18:57:00
:
Net-HTTP 6.06 might fix the bug when using IO::Socket::SSL but vmware is
using Crypt::SSLeay.
A similar fix for Net::SSL is required, the problem is that Net::SSL do not
yet have the pending method, it should be added, returning the value of
SSL_pending.
The correct fix is probably:
return 1 if $self->can('pending') && $self->pending;
and ask the Net::SSL maintainer to add the pending method.
From [email protected] on 2014-04-24 21:31:49
:
Net::HTTP-6.04 and newer are not compatible with Net::SSL
Net::SSL2.86 add the 'pending' method.
The attached patch fix Net:HTTP to use the pending method of Net:SSL.
A new release with this patch will be appreciated by all vmware users,
downgrading LWP and Net::SSL will no longer be required.
Jean-Louis
From https://www.google.com/accounts/o8/id?id=AItOawmgj_ZwMoFVbbbACmIegfUp5mGrRAE9rHA on 2014-10-23 22:50:51
:
On Thu Apr 24 17:31:49 2014, [email protected] wrote:
>
> A new release with this patch will be appreciated by all vmware users,
> downgrading LWP and Net::SSL will no longer be required.
This patch doesn't work for me to fix the VMware Perl SDK. What does work is to remove the parts in VICommon.pm that explicitly require Net::SSL or Crypt::SSLeay.
IO::Socket::SSL 2.006 changes EAGAIN to EWOULDBLOCK which breaks Net::HTTP 6.07 [rt.cpan.org #100580]
Migrated from rt.cpan.org#100580 (status was 'new')
Requestors:
From [email protected] on 2014-11-27 15:38:59:
Hi,
I am using IO-Socket-SSL-2.007 together with Net-HTTP-6.07 (and
libwww-perl-6.08) on Perl 5.20.1 for Windows and am receiving "read failed:
A non-blocking socket operation could not be completed immediately." errors.
I believe that these errors are the result of a modification made to
IO::Socket::SSL in version 2.006 that changed some errors from "EAGAIN" to
"EWOULDBLOCK", which have different values on Windows (see:
https://github.com/noxxi/p5-io-socket-ssl/commit/d95289de02ca9aede1c4f86481e
8fd1daa10cc7d).
I'm afraid that I am not particularly familiar with the internals of
Net::HTTP (and LWP) but modifying the checks for "EAGAIN" to check for both
"EAGAIN" and "EWOULDBLOCK" resolve the particular issue that I am
encountering.
Thanks
Peter
--- lib\Net\HTTP\Methods.pm.orig 2014-07-24 04:27:26.000000000 -0000
+++ lib\Net\HTTP\Methods.pm 2014-11-27 15:23:57.000000000 -0000
@@ -267,13 +267,13 @@
# need to read more data to find a line ending
READ:
{
die "read timeout" unless $self->can_read;
my $n = $self->sysread($_, 1024, length);
unless (defined $n) {
- redo READ if $!{EINTR} || $!{EAGAIN};
+ redo READ if $!{EINTR} || $!{EAGAIN} ||
$!{EWOULDBLOCK};
# if we have already accumulated some data let's at
least
# return that as a line
die "$what read failed: $!" unless length;
}
unless ($n) {
return undef unless length;
--- lib\LWP\Protocol\http.pm.orig 2014-07-25 04:13:08.000000000 -0000
+++ lib\LWP\Protocol\http.pm 2014-11-27 15:07:36.000000000 -0000
@@ -460,13 +460,13 @@
my $buf = ""; #prevent use of uninitialized value in SSLeay.xs
my $n;
READ:
{
$n = $socket->read_entity_body($buf, $size);
unless (defined $n) {
- redo READ if $!{EINTR} || $!{EAGAIN} || $!{ENOTTY};
+ redo READ if $!{EINTR} || $!{EAGAIN} || $!{EWOULDBLOCK} ||
$!{ENOTTY};
die "read failed: $!";
}
redo READ if $n == -1;
}
$complete++ if !$n;
return \$buf;
Can not determine whether the response body is complete [rt.cpan.org #87919]
Migrated from rt.cpan.org#87919 (status was 'new')
Requestors:
From [email protected] on 2013-08-18 04:25:36:
I add a method to do this.
See
https://github.com/libwww-perl/net-http/pull/5
Can't install v6.09 in perl 5.14.2 [rt.cpan.org #107351]
Migrated from rt.cpan.org#107351 (status was 'open')
Requestors:
From [email protected] on 2015-09-26 10:51:52
:
I'm trying to install latest cpan version of this module, in a ubuntu
precise with perl 5.14.2 and it fails passing tests:
Unpacking Net-HTTP-6.09.tar.gz
Net-HTTP-6.09/
Net-HTTP-6.09/Changes
Net-HTTP-6.09/MANIFEST
Net-HTTP-6.09/MANIFEST.SKIP
Net-HTTP-6.09/META.json
Net-HTTP-6.09/META.yml
Net-HTTP-6.09/Makefile.PL
Net-HTTP-6.09/README
Net-HTTP-6.09/lib/
Net-HTTP-6.09/t/
Net-HTTP-6.09/t/apache-https.t
Net-HTTP-6.09/t/apache.t
Net-HTTP-6.09/t/http-nb.t
Net-HTTP-6.09/t/http.t
Net-HTTP-6.09/lib/Net/
Net-HTTP-6.09/lib/Net/HTTP/
Net-HTTP-6.09/lib/Net/HTTP.pm
Net-HTTP-6.09/lib/Net/HTTPS.pm
Net-HTTP-6.09/lib/Net/HTTP/Methods.pm
Net-HTTP-6.09/lib/Net/HTTP/NB.pm
Entering Net-HTTP-6.09
Checking configure dependencies from META.json
Checking if you have ExtUtils::MakeMaker 6.58 ... Yes (6.94)
Running Makefile.PL
Configuring Net-HTTP-6.09 ... Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Net::HTTP
Writing MYMETA.yml and MYMETA.json
OK
Checking dependencies from MYMETA.json ...
Checking if you have IO::Uncompress::Gunzip 0 ... Yes (2.033)
Checking if you have URI 0 ... Yes (1.69)
Checking if you have IO::Select 0 ... Yes (1.20)
Checking if you have ExtUtils::MakeMaker 0 ... Yes (6.94)
Checking if you have IO::Socket::INET 0 ... Yes (1.31)
Checking if you have Compress::Raw::Zlib 0 ... Yes (2.033)
Building and testing Net-HTTP-6.09 ... cp lib/Net/HTTP/NB.pm
blib/lib/Net/HTTP/NB.pm
cp lib/Net/HTTP.pm blib/lib/Net/HTTP.pm
cp lib/Net/HTTPS.pm blib/lib/Net/HTTPS.pm
cp lib/Net/HTTP/Methods.pm blib/lib/Net/HTTP/Methods.pm
Manifying blib/man3/Net::HTTP.3pm
Manifying blib/man3/Net::HTTP::NB.3pm
Manifying blib/man3/Net::HTTPS.3pm
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM"
"-MTest::Harness" "-e" "undef *Test::Harness::Switches;
test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/apache-https.t .. skipped: Live tests disabled; pass --live-tests to
Makefile.PL to enable
t/apache.t ........ skipped: Live tests disabled; pass --live-tests to
Makefile.PL to enable
t/http-nb.t ....... 1/14
# Failed test at t/http-nb.t line 30.
# got: undef
# expected: '1'
print() on unopened filehandle GEN1 at /usr/lib/perl/5.14/IO/Handle.pm line 159.
# Failed test at t/http-nb.t line 32.
The test hangs on there and I I have to cancel.
From [email protected] on 2015-09-26 18:07:34
:
On 2015-09-26 03:51:52, [email protected] wrote:
> I'm trying to install latest cpan version of this module, in a ubuntu
> precise with perl 5.14.2 and it fails passing tests:
If it is convenient to do so, could you possibly try a few earlier versions and see if you get the same results? This will help determine if it's something that changed in a recent release, or if there is something else afoot.
The previous releases are available via the triangle pull-down menu near the top at https://metacpan.org/release/Net-HTTP (the tarball link is at 'download', in the left sidebar). You can also install earlier releases directly with the cpanminus client via 'cpanm Net::[email protected]' etc.
Thank you very much!
From [email protected] on 2016-04-27 15:33:06
:
I was getting timeout errors when trying to install the latest version (v6.09) on Centos 6. Version 6.06 installed successfully, but v6.07 failed.
I updated IO::Socket::INET6 from 2.56 to 2.72 and now Net::HTTP installs successfully.
Keith Carangelo
Tyring to install on a new MacOS Sierra 10.12.6, stock perl 15.8.2 [rt.cpan.org #123583]
Migrated from rt.cpan.org#123583 (status was 'new')
Requestors:
From [email protected] on 2017-11-10 12:29:23
:
t/http.t ............... ok
Net::HTTPS: SSL connect attempt failed with unknown error error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version at t/live-https.t line 34.
# Looks like your test exited with 255 before it could output anything.
t/live-https.t .........
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 6/6 subtests
Probably not your fault :)
Net::HTTP::NB may forget state when reading chunk [rt.cpan.org #20930]
Migrated from rt.cpan.org#20930 (status was 'open')
Requestors:
From [email protected] on 2006-08-10 06:07:05:
When Net::HTTP::NB::read_entity_body reads chunk,
if Net::HTTP::NB::my_read raises "Multi-read\n" exception,
${*$self}{'http_chunked'} remains an old value,
which should become a new value, $chunked.
From [email protected] on 2006-08-10 06:20:11:
Well, i should correct the report as following:
When Net::HTTP::NB::read_entity_body reads "http_first_body",
if Net::HTTP::NB::my_read raises "Multi-read\n" exception,
${*$self}{'http_chunked'} remains undefined,
which should become $chunked.
From [email protected] on 2006-08-10 06:31:46:
patch
*** Methods.pm.orig 2005-12-07 19:01:37.000000000 +0900
--- Methods.pm 2006-08-10 15:27:13.000000000 +0900
***************
*** 415,420 ****
--- 415,422 ----
# Read until EOF
}
+ ${*$self}{'http_chunked'} = $chunked;
+ ${*$self}{'http_bytes'} = $bytes;
}
else {
$chunked = ${*$self}{'http_chunked'};
From [email protected] on 2017-01-25 21:40:33:
migrated queues: libwww-perl -> Net-HTTP
IPv6 Address URLs Broken [rt.cpan.org #75618]
Migrated from rt.cpan.org#75618 (status was 'open')
Requestors:
Attachments:
![SYMCloud_RGB[2][3].png](https://rt.cpan.org/Ticket/Attachment/1047539/547454/SYMCloud_RGB%5B2%5D%5B3%5D.png){kind=link}
From [email protected] on 2012-03-08 00:37:02:
Net::HTTP doesn't appear to handle ipv6 addresses correctly.
In http_configure of Net/HTTP/Methods.pm, the code will search for something that appears to be a port at the end of PeerAddr (or PeerHost). When using an ipv6 style address, this pattern may incorrectly match the last segment of an ipv6 address.
sub http_configure {
my($self, $cnf) = @_;
die "Listen option not allowed" if $cnf->{Listen};
my $explict_host = (exists $cnf->{Host});
my $host = delete $cnf->{Host};
my $peer = $cnf->{PeerAddr} || $cnf->{PeerHost};
if (!$peer) {
die "No Host option provided" unless $host;
$cnf->{PeerAddr} = $peer = $host;
}
if ($peer =~ s,:(\d+)$,,) { # <-- BUG HERE - $peer could be an ipv6 address
$cnf->{PeerPort} = int($1); # always override
}
<snip>
Sample Code using LWP::UserAgent
#!/usr/bin/env perl
use Net::INET6Glue::INET_is_INET6;
use LWP::UserAgent;
my $url = 'http://[1234:1234:1234:5:abc:abcd:abc1:123]:80/foo/bar.pl?param=true';
my $user_agent = LWP::UserAgent->new;
my $request = HTTP::Request->new(GET => $url);
my $response = $user_agent->request($request);
if ($response->is_success) {
print "OK\n";
} else {
die($response->status_line);
}
The error is shown as:
500 Can't connect to 1234:1234:1234:5:abc:abcd:abc1:123:80 (Connection refused) at ./bug.pl line 16.
Setting EXTRA_SOCK_OPTS turns out to be an awful workaround.
@LWP::Protocol::http::EXTRA_SOCK_OPTS = (PeerAddr => '1234:1234:1234:5:abc:abcd:abc1:123:80');
Nick Lamkins
Sr. Software Engineer, Symantec Corporation
www.symantec.com<http://www.symantec.com/>
________________________________
Office: (503) 614-5039 Fax: (503) 614-5060
[email protected]
________________________________
[cid:9CC5DD25-B7F1-488B-8109-2C9197866A89]
This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and (i) destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication.
From [email protected] on 2013-01-24 01:07:46:
I have the same problem. The workaround seems very clumsy. Is there any
intention to fix this?
Could this just be skipped for IPv6 addresses?
From [email protected] on 2013-04-10 14:51:35:
I've spent some time over past few days trying to figure out exactly same
issue as is described here. I wish I've had find this bug report sooner.
Anyway, I've reached the same conclusion as Nick. That code should be
skipped for IPv6 or better regexp should be in place to correctly extract
port from all addresses.
What I've found to be easier workaround than setting EXTRA_SOCK_OPTS is to
use double square brackets. I've used same example code above just added some
debugging output to Net::HTTP::Methods
my $url = 'http://[fc00::3]/';
$VAR1 = {
'Proto' => 'tcp',
'PeerAddr' => 'fc00::3',
'SendTE' => 1,
'PeerPort' => 3, # PeerPort incorrectly set to 3
'KeepAlive' => ''
};
my $url = 'http://[[fc00::3]]/';
$VAR1 = {
'Proto' => 'tcp',
'PeerAddr' => '[fc00::3]',
'SendTE' => 1,
'PeerPort' => 80, # PeerPort is now correctly set to default
'KeepAlive' => ''
};
From [email protected] on 2014-07-22 21:40:03:
I humbly offer:
https://github.com/libwww-perl/net-http/pull/10
https://github.com/libwww-perl/libwww-perl/pull/58
The combination will use IO::Socket::IP or IO::Socket::INET6 (if found); and uses URI to do host address parsing (in order to correctly parse [2001:db8::1]:80).
From [email protected] on 2014-07-25 22:43:24:
My patches appear to be accepted, and a new release produced.
Please consider updating to these packages:
Net::HTTP (6.07)
LWP (6.080
URI (1.64)
Can't install v6.09 in perl 5.14.2
I'm trying to install latest cpan version of this module, in a ubuntu precise with perl 5.14.2 and it fails passing tests:
Unpacking Net-HTTP-6.09.tar.gz
Net-HTTP-6.09/
Net-HTTP-6.09/Changes
Net-HTTP-6.09/MANIFEST
Net-HTTP-6.09/MANIFEST.SKIP
Net-HTTP-6.09/META.json
Net-HTTP-6.09/META.yml
Net-HTTP-6.09/Makefile.PL
Net-HTTP-6.09/README
Net-HTTP-6.09/lib/
Net-HTTP-6.09/t/
Net-HTTP-6.09/t/apache-https.t
Net-HTTP-6.09/t/apache.t
Net-HTTP-6.09/t/http-nb.t
Net-HTTP-6.09/t/http.t
Net-HTTP-6.09/lib/Net/
Net-HTTP-6.09/lib/Net/HTTP/
Net-HTTP-6.09/lib/Net/HTTP.pm
Net-HTTP-6.09/lib/Net/HTTPS.pm
Net-HTTP-6.09/lib/Net/HTTP/Methods.pm
Net-HTTP-6.09/lib/Net/HTTP/NB.pm
Entering Net-HTTP-6.09
Checking configure dependencies from META.json
Checking if you have ExtUtils::MakeMaker 6.58 ... Yes (6.94)
Running Makefile.PL
Configuring Net-HTTP-6.09 ... Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Net::HTTP
Writing MYMETA.yml and MYMETA.json
OK
Checking dependencies from MYMETA.json ...
Checking if you have IO::Uncompress::Gunzip 0 ... Yes (2.033)
Checking if you have URI 0 ... Yes (1.69)
Checking if you have IO::Select 0 ... Yes (1.20)
Checking if you have ExtUtils::MakeMaker 0 ... Yes (6.94)
Checking if you have IO::Socket::INET 0 ... Yes (1.31)
Checking if you have Compress::Raw::Zlib 0 ... Yes (2.033)
Building and testing Net-HTTP-6.09 ... cp lib/Net/HTTP/NB.pm blib/lib/Net/HTTP/NB.pm
cp lib/Net/HTTP.pm blib/lib/Net/HTTP.pm
cp lib/Net/HTTPS.pm blib/lib/Net/HTTPS.pm
cp lib/Net/HTTP/Methods.pm blib/lib/Net/HTTP/Methods.pm
Manifying blib/man3/Net::HTTP.3pm
Manifying blib/man3/Net::HTTP::NB.3pm
Manifying blib/man3/Net::HTTPS.3pm
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/apache-https.t .. skipped: Live tests disabled; pass --live-tests to Makefile.PL to enable
t/apache.t ........ skipped: Live tests disabled; pass --live-tests to Makefile.PL to enable
t/http-nb.t ....... 1/14
# Failed test at t/http-nb.t line 30.
# got: undef
# expected: '1'
print() on unopened filehandle GEN1 at /usr/lib/perl/5.14/IO/Handle.pm line 159.
# Failed test at t/http-nb.t line 32.
The test hangs on there and I I have to cancel.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.