W3C home > Mailing lists > Public > uri@w3.org > February 2004

Re: localhost

From: Adam M. Costello BOGUS address, see signature <BOGUS@BOGUS.nicemice.net>
Date: Mon, 16 Feb 2004 20:08:39 -0500
Message-Id: <4.2.0.58.J.20040216200826.05f1d200@localhost>
To: uri@w3.org




Martin Duerst <duerst@w3.org> wrote:

 > I think the 'localhost' convention should only apply to reg-names that
 > are domain/host names.  I think it's inappropriate to impose this
 > convention on other registry names; they may have completely different
 > needs (i.e. not actually refering to machines,...) or syntax (e.g.
 > numerical,...).

That seems reasonable.

 > - On the other hand, 'localhost' should work for all dns-based
 > schemes.  "Individual URI schemes can require support for this
 > custom." may suggest otherwise.

Graham Klyne <GK@ninebynine.org> replied:

 > If it does work for all DNS-based schemes (or Internet hostname based
 > schemes), I think that's a feature of Internet host naming, not of
 > URIs.

Historically it's neither and both.

Internet host naming: localhost is a customary but non-standardized host
name refering to an IP loopback address (which means packets sent there
go to the machine you're running on).  RFC-2606 documents this custom,
but requires nothing. localhost typically exists in a local config file
(like /etc/hosts on Unix-like systems), and sometimes in DNS servers
(but I notice that it's not in the DNS servers of my ISP, nor in the
root servers).

URIs: RFC-1738 defined a meaning for localhost in file: URIs, but not
in any of the other URI schemes specified in that document (including
http, ftp, telnet, gopher).  In file: URIs, there was no dependence on
localhost existing in the host database; localhost was required to refer
to the machine you're running on, regardless.

This difference in the specification of file: versus other URI schemes
has made its way into implementations.  For example, Firefox and w3m on
Linux both exhibit the same behavior (running on arwen.nicemice.net):

works: http://arwen.nicemice.net/
works: http://localhost/
fails: http:///

works: file:///etc/motd
works: file://localhost/etc/motd
fails: file://arwen.nicemice.net/etc/motd

ftp works like http.

There are two independent features that file: has that http: & ftp:
lack:

1) Interpretation of localhost without depending on its presence in the
host database.

2) Interpretation of an empty authority as equivalent to localhost.

Either or both or neither of these features could be recommended for
future URI schemes that use domain names for their reg-names.

The current draft recommends (2) for all future schemes using reg-names,
not just domain names.  Regarding (1), the current draft is unclear (to
me at least).

For (1), one route would be to let file: be the oddball, and recommend
that all future schemes depend on the host database to define localhost,
like http: and ftp: do.  The URI spec would mention the customary
meaning (and perhaps cite RFC-2606), but would not have the authority to
require localhost to exist on every host.

Another route is to recommend that all future schemes require localhost
to be recognized and interpreted as the local machine, like file:, which
in practice means that URI resolvers will need to check for localhost
before doing the host lookup (unless they can be sure how localhost is
handled on their platform).

AMC
http://www.nicemice.net/amc/
Received on Monday, 16 February 2004 20:47:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:07 UTC