[PATCH] Accept file://localhost/ style urls as local

Jonathan S. Shapiro shap at eros-os.com
Wed Sep 12 07:39:22 CDT 2007

On Wed, 2007-09-12 at 13:50 +0200, Christian Ebert wrote:

> Accept
> file:///path
> file:/path
> file://localhostname/path

>From memory, I believe that file:///path is a malformed URI and should
not be accepted. The general pattern for file:// and http[s]:// URI's


where path defaults to / if not present. Note that the host portion is
not optional if the leading // is present.

Similarly for http[s] URI's

For other schemes, the layout of everything after the : is left to be
defined by the scheme. As a matter of wide practice, ssh: URI's should
obey the rule given above. In mercurial they do not, which is a bug.

In general the URI scheme does not permit for the specification of
relative paths at all, because relative paths do not make sense in a
distributed name space. The "extra slash" hack that mercurial is
currently using to distinguish relative remote file names is
incompatible with the generally accepted format of the ssh: scheme, and
as a practical matter it simply isn't necessary at all.

Unfortunately, there is no good means to deal simultaneously with the
union-like mechanism of hg-ssh and fully rooted filenames -- the problem
here is that we need to overload "/". In my opinion, the best way to
deal with this (within the intent of the URI scheme) is to view the list
of directories on the ssh line as forming a union directory that defines
"/" in the path portion of the URI and stop trying to overload these two
things. Unfortunately, this breaks current mercurial conventions.

Aside: the entire concept of an ssh: URI is malformed within the
conception of URIs. ssh is a transport, not a protocol. Various attempts
have been made to generalize URI's to deal with this, all of them pretty
ugly. For example, some systems use a tweaked scheme that might take the


My recollection of the URI specification may not be quite right, but
here is my point: if we are going to do URIs, we should do them in
accordance with the specification and widely accepted common practice.
Making up our own meanings and our own conventions is merely a way to
impose future, ad-hoc compatibility requirements on ourselves. It is
also brittle: we don't want to be in a situation where the URI spec
moves forward and we cannot because we hacked the URI concept.

Summary: quit making things up as you go and read the spec!


> Do not accept
> file:path/not/starting/with/slash
> file://invalidlocalhostname/path
> diff --git a/mercurial/util.py b/mercurial/util.py
> --- a/mercurial/util.py
> +++ b/mercurial/util.py
> @@ -14,7 +14,7 @@ platform-specific details from the core.
>  from i18n import _
>  import cStringIO, errno, getpass, popen2, re, shutil, sys, tempfile, strutil
> -import os, stat, threading, time, calendar, ConfigParser, locale, glob
> +import os, stat, threading, time, calendar, ConfigParser, locale, glob, socket
>  try:
>      set = set
> @@ -1683,12 +1683,30 @@ def bytecount(nbytes):
>              return format % (nbytes / float(divisor))
>      return units[-1][2] % nbytes
> +def _localhostnames():
> +    hl = []
> +    for h in socket.gethostbyaddr(socket.gethostname()):
> +        if isinstance(h, str):
> +            h = [h]
> +        hl += h
> +    return hl
> +
>  def drop_scheme(scheme, path):
>      sc = scheme + ':'
>      if path.startswith(sc):
>          path = path[len(sc):]
> +        if scheme == 'file' and not path.startswith('/'):
> +            raise Abort(_('invalid file url'))
>          if path.startswith('//'):
>              path = path[2:]
> +            if scheme == 'file' and not path.startswith('/'):
> +                if path[:10] in ('localhost/', ''):
> +                    return path[9:]
> +                for h in _localhostnames():
> +                    if path.startswith(h + '/'):
> +                        return path[len(h):]
> +                inv = path.split('/', 1)[0]
> +                raise Abort(_('%s: invalid local hostname') % inv)
>      return path
>  def uirepr(s):
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
Jonathan S. Shapiro
Managing Director
The EROS Group, LLC
www.coyotos.org, www.eros-os.org

More information about the Mercurial-devel mailing list