Toby said:
Because as I have repeatedly said, "localhost" is the only useful value
for the "host" part of "file://" URLs.
Yes, I know, you have said so repeatedly, but when somebody who is not
an originating authority on a subject says something to me, even
repeatedly, that appears non-obvious, counterintuitive, or even
contradictory to me (a person who frequently goes directly to the
official specs and standards and recommendations) AND is not supported
by the authoritative information I have found on the subject, I tend not
to take it as authoritative, regardless of the number of times it might
have been repeated and even if he generally knows what he is talking
about. And I get extra suspicious when I ask for a reference and the
response I get is indignation that I didn't cave in from sheer repetition.
Putting a host in (either domain name or IP address) does *not* mean that
the client must attempt to fetch the file from that host via some sort of
network protocol -- it means that the user may access the file from that
host.
I gotta laugh here. The client runs on top of the operating system, and
the only way it can access other machines on the local system is via the
tools provided by the operating system for accessing network resources.
How *else* do you think a client is supposed to support access to local
network resources?
So "file://HOST/SOMEFILE" is not an instruction to the client to
download SOMEFILE from HOST, but is an instruction to the user to access
SOMEFILE from HOST -- this might require a physical walk over to HOST to
access the file.
That makes no sense. How many users are wired so that if
file://HOST/SOMEFILE
appears on their screens, they suddenly feel compelled to walk over to
HOST with a recordable CD-R on their hands to burn a copy of SOMEFILE
onto it? Or are you talking about the case where somebody has this
tattooed on his arm, and then someone comes along and presses it?
Honestly, I don't understand what you are talking about when you call
this an "instruction to the user".
If a browser resolves "file://HOST/SOMEFILE" by using CIFS (i.e. the
protocol by which Windows machines share files and printers) to retrieve
the file automatically, then that is a proprietary extension to the file
protocol -- and this seems to be what IE is doing. Hardly surprising.
File URLs *can* be stated relative to another machine -- that's why the
facility to specify a host exists. However, doing so is useless, because
the file protocol specifies no mechanism which can be used to retrieve the
file from another machine -- you just need to walk over there and access
it.
For example:
file://ophelia.g5n.co.uk/vol/music/pulp_-_common_people.ogg
refers to a particular file on my computer. However, that is useless to
anyone who isn't logged into my computer.
It shouldn't be useless to anyone who has file access via some file
access protocol to a host recognized on his or her system as
ophelia.g5n.co.uk. Again, you keep saying so, but you don't say why and
I don't see why.
As I have SAMBA installed, if
you were on my LAN however, you could access the same file at:
\\ophelia\juke\pulp_-_common_people.ogg
Yes, I can do this from the Run box launched from my Windows Start menu,
and I can do this by typing a similar line into Windows File Explorer.
Knowing that UNC path, the file protocol URL must consist of:
file://localhost/\\ophelia\juke\pulp_-_common_people.ogg
file:///\\ophelia\juke\pulp_-_common_people.ogg
(I like to use backslashes in the UNC path because it makes it clearer as
to which slashes are part of the path and which are part of the file://
protocol prefix to it.)
But without knowing the UNC path, there's no way you could access that
file from your computer. So it only makes practical sense to use file://
URLs which are relevant to your local machine.
Again I don't understand. You *are* using the UNC path. You're just
sticking extra slashes in front of it to make it relative to your computer.
If my company has a server called "central" and in a share on that
machine called "public" that everybody logged into the LAN has access
to, there is a phone list called phonelist.doc, then the address
\\central\public\phonelist.doc
is the address of--the UNC path to this list from every single computer
on the LAN. It is not *relative* *to* anybody else's computer, any more
than
www.example.com in the URL
http://www.example.com/segment/file
is *relative* *to* the machine on which a client trying to access this
resource is running. It is an absolute location, and
file://central/public/phonelist.doc
is formally an absolute URL for a resource on the file host "central".
