Skip Menu |

This queue is for tickets about the RPC-XML CPAN distribution.

Report information
The Basics
Id: 120472
Status: open
Priority: 0/
Queue: RPC-XML

People
Owner: rjray [...] blackperl.com
Requestors: ppisar [...] redhat.com
Cc: PLICEASE [...] cpan.org
AdminCc:

Bug Information
Severity: Important
Broken in: 0.80
Fixed in: (no value)



Subject: IPv6 support
When HTTP::Daemon supports IPv6 <https://rt.cpan.org/Public/Bug/Display.html?id=91699>, RPC-XML-0.80 t/40_server.t test will fail like this: not ok 19 - RPC::XML::Server::url method (set) # Failed test 'RPC::XML::Server::url method (set)' # at t/40_server.t line 187. # 'http://[::1]:42761/' # doesn't match '(?^:http://(127[.]0[.]0[.]1|localhost|localhost[.]localdomain|localhost4|localhost4[.]localdomain4|localhost[.]localdomain|localhost6|localhost6[.]localdomain6):42761)' and Not an ARRAY reference at t/40_server.t line 332. # Looks like your test exited with 255 just after 43. The first failure can be easily fixed (I have a patch), but the second is one is more troublesome. It crashes on: $res = $res->value->value; → is($res->[2], inet_ntoa(inet_aton('localhost')), because localhost resolves to ::1 IPv6 address and inet_ntoa supports IPv4 only. This could be also corrected, by the issue with $res whose values come from code: $res = $srv->add_method({ name => 'perl.test.suite.peeraddr', signature => [ 'array' ], code => sub { my $server = shift; my $ipaddr = inet_aton($server->{peerhost}); my $peeraddr = RPC_BASE64 $server->{peeraddr}; my $packet = pack_sockaddr_in($server->{peerport}, $ipaddr); $packet = RPC_BASE64 $packet; [ $peeraddr, $packet, $server->{peerhost}, $server->{peerport} ]; } }); and especially $server->{peeraddr} is documented in RPC::XML as: peeraddr This is the address part of a packed SOCKADDR_IN structure, as returned by "pack_sockaddr_in" in Socket, which contains the address That means the documentation explicitly allows only IPv4 addresses. How could this be fixed? It's good to know that "an address part of a packaged structure" itself is useless because one needs to know address family to interpret it correctly. One could add new $server->{family} element to carry address family. Or one could change the $server->{peeraddr} meaning to deliver complete packed structure including IP address, port, and address family (output of pack_sockaddr_in or pack_sockaddr_in6). I have not yet studied Net::Server how it deals with it.
From: ppisar [...] redhat.com
Dne St 01.bře.2017 11:39:09, ppisar napsal(a): Show quoted text
> When HTTP::Daemon supports IPv6 > <https://rt.cpan.org/Public/Bug/Display.html?id=91699>, RPC-XML-0.80 > t/40_server.t test will fail like this: >
Attached patch should fix it.
Subject: RPC-XML-0.80-IPv6-support.patch

Message body is not shown because it is too large.

Thanks for the report and the patch. I'll examine it and integrate it as soon as I can! Randy -- Randy J. Ray rjray@blackperl.com randy.j.ray@gmail.com
On 2017-03-05 12:41:36, RJRAY wrote: Show quoted text
> Thanks for the report and the patch. I'll examine it and integrate it > as soon as I can!
I see the problem, too (on CentOS 7 and Fedora 28 systems).
Subject: Re: [rt.cpan.org #120472]
Date: Sat, 2 Mar 2019 00:10:17 +0100
To: bug-RPC-XML [...] rt.cpan.org
From: Fabian Grünbichler <f.gruenbichler [...] proxmox.com>
the patch attached in this queue actually has a bug itself, which the following diff (full patch/commit[1]) fixes: it does break for IPv4 only systems where 'localhost' only resolves to '127.0.0.1', since '127.0.0.1' cmp '127.0.0.1' == 0. in case resolve (which ignores $res->[0]/$family) returns '::1' (or any other value) in addition to '127.0.0.1', the problem is actually hidden since '::1' cmp '127.0.0.1' is truthy, not false. switching to 'eq' does the right thing, since we don't care about ordering. 1: https://salsa.debian.org/perl-team/modules/packages/librpc-xml-perl/commit/31c9c4a78dcff0beb5c19d7363848c08c9b319f9 diff --git a/t/40_server.t b/t/40_server.t index 379b956..86c49ed 100644 --- a/t/40_server.t +++ b/t/40_server.t @@ -317,7 +317,7 @@ SKIP: { } $res = $res->value->value; - ok(grep({ $_ cmp $res->[3]} resolve($res->[0], 'localhost')), + ok(grep({ $_ eq $res->[3]} resolve($res->[0], 'localhost')), 'Third live req: Correct IP addr from peerhost'); is($res->[1], Socket::inet_pton($res->[0], $res->[3]), 'Third request: peeraddr packet matches converted peerhost'); diff --git a/t/40_server_xmllibxml.t b/t/40_server_xmllibxml.t index 8aeaece..68952f4 100644 --- a/t/40_server_xmllibxml.t +++ b/t/40_server_xmllibxml.t @@ -214,7 +214,7 @@ SKIP: { } $res = $res->value->value; - ok(grep({ $_ cmp $res->[3]} resolve($res->[0], 'localhost')), + ok(grep({ $_ eq $res->[3]} resolve($res->[0], 'localhost')), 'Third live req: Correct IP addr from peerhost'); is($res->[1], Socket::inet_pton($res->[0], $res->[3]), 'Third request: peeraddr packet matches converted peerhost');
Dne Pá 01.bře.2019 18:17:23, f.gruenbichler@proxmox.com napsal(a): Show quoted text
> the patch attached in this queue actually has a bug itself, which the > following diff (full patch/commit[1]) fixes: > > it does break for IPv4 only systems where 'localhost' only resolves to > '127.0.0.1', since '127.0.0.1' cmp '127.0.0.1' == 0. in case resolve > (which ignores $res->[0]/$family) returns '::1' (or any other value) > in > addition to '127.0.0.1', the problem is actually hidden since '::1' > cmp > '127.0.0.1' is truthy, not false. switching to 'eq' does the right > thing, since we don't care about ordering. >
Thanks for spotting it. It actually breaks any time 'localhost' resolves to one address only. Your fix is right.