> ... 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://* http://info.cern.ch:8001/*
> pass file://fred.cmu.edu/* file:/afs/cs.cmu.edu/*
> pass ftp://ftp.cnu.edu/pub/* 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
useful
> 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,
for
> instance.)
>
> > At least in
> the version of the WWW library that Mosaic uses, the URL
> "file:/afs/cs.cmu.edu..." 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
incorrectly,
> and really *should* be reading from the local filesystem, let me
know.)
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
Mosaic
> the URL "file:///afs/cs.cmu.edu..." seems to force a check of the
local
> 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
work
> 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
to
> a file on a local filesystem in an absolute URL is to include the
name
> of the host the program is executing on (using whatever
capitalization
> 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
Mosaic
> 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://cluster.cmu.edu/* 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.
Tim
> John Ockerbloom
>