Re: WWW: Local file handling

Tim Berners-Lee <>
Date: Tue, 11 May 93 12:25:16 +0100
From: Tim Berners-Lee <>
Message-id: <>
Subject: Re: WWW: Local file handling
Tim bl:

> ... as in the server to allow mappings to be made.
> You can now run [from next release 2.05 on] www as

>         www -r  www.conf
> where www.conf contains lines like

> pass    wais://*      *
> pass    file://*   file:/afs/*
> pass* file:/ftp/pub/*

> for example.  The rule file is not very powerful, not full regexp,
> but it is more flexible than just tackling the file: case.

> ----

> This will be quite useful; thanks! (In particular, it's quite  
> for mirrored sites.  For instance, I may want requests for a HTTP
> server in New Zealand to go to some mirrored site closer to home,  
> instance.)

> > At least in
> the version of the WWW library that Mosaic uses, the URL
> "file:/afs/" does NOT read from the local filesystem,
> but rather from the last filesystem accessed.

That sounds very strange. That is not how it should work.  The
parser should clear the host field if "file:" is present. If the
field is clear, then local access it assumed.  The relative names
are hierarchical, not a matrix -- you can't pick up a hostname
from another protcol for example.

> So if I'm in an FTP
> directory at Bellcore, and then try to jump to a "file:/afs/cs..."
> URL, it will attempt to find the file at Bellcore, rather than back
> on my local filesystem.  (If Mosaic is handling this case  
> and really *should* be reading from the local filesystem, let me  

It sounds as though there is some difference in behaviour.  This will
go away when Mosaic picks up the new library.

> (Currently I use a hack to force local filesystem lookup, as under  
>  the URL "file:///afs/" seems to force a check of the  
>  filesystem due to the empty host name.  But this isn't something
>  defined in the HTML specification, and in fact I think it doesn't  
>  for other WWW browsers.)

Sounds as though they have used their own code for URL parsing.

> As far as I can tell, the only way currently to unequivocally refer  
> a file on a local filesystem in an absolute URL is to include the  
> of the host the program is executing on (using whatever  
> scheme the name-lookup routine prefers) in the URL.  A static rule
> file will not fix this problem unless there's a rule file for every
> machine the program runs on.  And in this environment, we run  
> and other WWW tools on a large variety of workstations.

There is of course one good reson for explicitly declaring the  
hostname for a local file: that is, in order that people on other
machines which don't have it don't get confused.  The URLs are
supposed to be quatable anywhere. If you use a hostname, then even
if the file is not retrievable from off that host, then at least
a foreign person following the link will get an reasonable error.
Th eidea of a URL is that if one perosn quotes it and the other  
person follows it, then they will be talking about the same object.
If one guy says "look in file /rtc/printcap on line 100"
and th eother guy does so, they get confused. The reference
doesn't work.

How about in your case, if you have a whole cluster or campus which
has the same file system, invent a name for it or use one master
hostname.  This would appear in all the absolute links.  The
rule file would then map it to a local name

map file://* file:///*

This can be ina cluster-wide rule file.
I have put in the dummy name "localhost" (not case sensitive)
into the next release,
so this can be made more explicit.  It will be equivalent to an
empty host field.


> John Ockerbloom