Re: WWW: Local file handling

Tim Berners-Lee (
Tue, 11 May 93 12:25:16 +0100

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