Skip Menu |

This queue is for tickets about the libwww-perl CPAN distribution.

Report information
The Basics
Id: 50252
Status: resolved
Priority: 0/
Queue: libwww-perl

People
Owner: Nobody in particular
Requestors: lilstevey [...] cpan.org
Cc:
AdminCc:

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



Subject: HTTP::Daemon returns resolved hostname rather than localhost
I'm running strawberry perl 5.8... on windows. The following code: my $d = HTTP::Daemon->new( LocalAddr => "localhost" ) || die; print "Please contact me at: <URL:", $d->url, ">\n"; Appears to print for the url the name of the windows pc i'm sitting at rather than the hostname. On the pc I'm sitting at, the url returned isn't reachable, and the connection times out if I attempt to get to http://servername:$port/ ( ie the return value of $d->url ) .... if, however I go via http://localhost:$port/ ( what I asked for ) everything works as expected. This behavour appears to break the tests for WWW::Mechanize on strawberry perl 5.8 - preventing installation of this package, packages which depend on it, and hanging the CPAN shell in the process. After a casual look at the source and docs of HTTP::Deamon I can't see a method returning either the port or the hostname specified in the constructor, otherwise I could have sent a nice patch to the owner of WWW::Mechanize. There are a few different ways of implementing what looks to me like a simple fix - I assume the behavour of $d->url may be relied upon elsewhere and hence adding either a method to return $port, or another one to behave as $d->url, but instead returning the requested address passed in the constructor would assist greatly in this. Its a shame because it prevents installation of some modules on strawberry perl which raises the barrier of entry to this variety of perl on windows.
Sorry - typo: Appears to print for the url the name of the windows pc i'm sitting at rather than the hostname. should read: Appears to print for the url the name of the windows pc i'm sitting at rather than the hostname requested ( ie localhost ). On Tue Oct 06 09:55:40 2009, LILSTEVEY wrote: Show quoted text
> I'm running strawberry perl 5.8... on windows. > > The following code: > > my $d = HTTP::Daemon->new( LocalAddr => "localhost" ) || die; > print "Please contact me at: <URL:", $d->url, ">\n"; > > Appears to print for the url the name of the windows pc i'm sitting at > rather than the hostname. > > On the pc I'm sitting at, the url returned isn't reachable, and the > connection times out if I attempt to get to http://servername:$port/ ( > ie the return value of $d->url ) .... > > if, however I go via http://localhost:$port/ ( what I asked for ) > everything works as expected. > > This behavour appears to break the tests for WWW::Mechanize on > strawberry perl 5.8 - preventing installation of this package, packages > which depend on it, and hanging the CPAN shell in the process. After a > casual look at the source and docs of HTTP::Deamon I can't see a method > returning either the port or the hostname specified in the constructor, > otherwise I could have sent a nice patch to the owner of WWW::Mechanize. > There are a few different ways of implementing what looks to me like a > simple fix - I assume the behavour of $d->url may be relied upon > elsewhere and hence adding either a method to return $port, or another > one to behave as $d->url, but instead returning the requested address > passed in the constructor would assist greatly in this. > > Its a shame because it prevents installation of some modules on > strawberry perl which raises the barrier of entry to this variety of > perl on windows.
Isn't the problem here a misconfigured system? First 'localhost' really ought to map to 127.0.0.1; secondly the outgoing ip-address should map to a hostname that can be looked up to give the IP address back. LWP ships with a 'talk-to-ourself' script that tries to discover this misconfiguration and then skips the tests that tries set up a connection to HTTP::Daemon. HTTP::Daemon doesn't even look at the LocalAddr argument passed in. It's processed by the IO::Socket::INET base class.
Hi, Thanks for the constructive comments. After looking a little deeper it turns out that on one of the systems I tested I accidentally used Localaddr rather than LocalAddr as an argument to the constructor ( though www::mechanize test suite did fail on several attempts ). I feel like a bit of a plum - comes from using a strictly typed language for too long I guess. Sorry for using up some of your time though. It seems a bit "not perl" to suggest to the author of IO::Socket::INET that they check the relative size of the hash formed in the constructor arguments against a template thusly %template = ( LocalAddr => undef, etc => undef, etcetc => undef ); %args = ( %template,@_ ) if ( scalar %args != scalar %template ){ die "Invalid argument" } but I do find the ease of screwing up such parameters ( largly due to my own inability to type ) slightly frustrating. I'll also admit to being slightly lazy on the port argument - $d->sockport; would indeed be sufficient - though ( genuinely ) I'm not sure how that sits with the law of demeter. However - looking at the url method: sub url { my $self = shift; my $url = $self->_default_scheme . "://"; my $addr = $self->sockaddr; if (!$addr || $addr eq INADDR_ANY) { require Sys::Hostname; $url .= lc Sys::Hostname::hostname(); } else { $url .= gethostbyaddr($addr, AF_INET) || inet_ntoa($addr); } my $port = $self->sockport; $url .= ":$port" if $port != $self->_default_port; $url .= "/"; $url; } It seems that on the system which causes the error, it might delegate the task to Sys::Hostname which I assume then detects the pc name - this then would be behavour of HTTP::Daemon? If there was a varient of $d -> url that threw an exception at this point, rather than delegating it, then couldn't the calling program decide to either just use the hostname passed into the constructor or to delegate the task to Sys::Hostname its self? I'm unsure what happened to one of the two pcs to configure its self so it worked ( from an cpan WWW::Mechanize perspective - it failed on one for ages before slipping in ) but something seems slightly odd - i'll try to do some more digging to discover more. Thanks again for your comments - they made me re-examine one of my systems and discover an error I had made in my investigation. All the best, Steve On Tue Oct 06 16:26:39 2009, GAAS wrote: Show quoted text
> Isn't the problem here a misconfigured system? First 'localhost' > really ought to map to > 127.0.0.1; secondly the outgoing ip-address should map to a hostname > that can be looked up > to give the IP address back. > > LWP ships with a 'talk-to-ourself' script that tries to discover this > misconfiguration and then > skips the tests that tries set up a connection to HTTP::Daemon. > > HTTP::Daemon doesn't even look at the LocalAddr argument passed in. > It's processed by the > IO::Socket::INET base class.