invalid ip addr on hg serve
mads at kiilerich.com
Thu Mar 27 19:15:12 CDT 2008
Adrian Buehlmann wrote, On 03/27/2008 07:14 PM:
> But with (A)
> $ hgd serve -v
> listening at http://snoopy:8000/ (*:8000)
> maybe someone will ask then what the star means :-)?
> Some more ideas:
> (B) listening at http://snoopy:8000/ (address *:8000)
> (C) listening on address *:8000 (http://snoopy:8000/)
Mercurial knows that it is listening precisely at 0.0.0.0:8000, and from
the local host the repository can be accessed at http://0.0.0.0:8000/,
so that address / URL should be the first to mention.
Because of the possibility of bogus or smart dns or PAT/NAT then
Mercurial can't know for sure which url other hosts can access the
repository on. But there is a good chance that other hosts can access
the repo using the "servers" local hostname. That should also work locally.
So I suggest C or a variation of it:
listening on address *:8000 (probably http://snoopy:8000/)
If a host has several IP adresses then each of them will probably also
have their own DNS name (which might be related to local hostname).
Mercurial can't know which URL to prefer, so perhaps it should show all
the possible URLs...
I could argue for using IP in the url instead of a DNS name. hg serve is
usually running temporarily on workstations; it is very unlikely that
the IP address changes while it is running. And workstations often get
IP address from DHCP and will thus get another FQDN and thus require
another URL anyway. And workstations are quite likely (more than
servers) to have bogus setup of DNS for the local hostname. So why use
DNS names at all?
But when I look in the source to find out what is done today I get very
confused. mercurial/hgweb/server.py around line 272:
self.fqaddr = socket.getfqdn(address)
fqaddr = address
According to Google this is the only example of socket.getaddrbyhost the
world has ever seen.
It isn't obvious what exceptions the except was expected to catch, but
apparently it is always "AttributeError: 'module' object has no
The final binding to "fqaddr" is never used - I wonder if it should be
I don't know how it should work, but there seems to be an issue that
should be fixed before we start nitpicking on the message format.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3422 bytes
Desc: S/MIME Cryptographic Signature
Url : http://selenic.com/pipermail/mercurial/attachments/20080328/39acde23/attachment.bin
More information about the Mercurial