Re: File protocol host need not be limited to "localhost"
Gisle Aas (aas@sn.no)
12 Sep 1998 13:05:05 +0200
jeff.kowalski@autodesk.com writes:
> Was a decision reached on this proposal?
What I have done is to reimplement the mapping for file:-URLs to local
file names in the new URI.pm modules, and my next plan is to make LWP
use URI.pm instead of the old URI::URL. That should (I hope) give you
what you want.
The current URI interface to file:-URIs look like this:
$u = URI::file->new( $filename, [$os]);
$u->file([$os])
$u->dir([$os]);
The URI::file constructor takes a local filename and maps it into a
file:-URL. The optional $os argument let you specify what kind of
operating system this file name comes from. It defaults to $^O,
i.e. assumes file names for the local system.
The $u->file and $u->dir methods map file:-URIs back to local file
names (and directory names). These also take an optional operating
system type.
Some examples:
print URI::file->new("a:\\windows\\system", "dos");
==> file://a:/windows/system
print URI::file->new("../../foo", "dos");
==> ../../foo
print URI::file->new("\\\\server\\dir\\file.doc", "dos");
==> file://server/dir/file.doc
print URI::file->new("a:foo", "dos");
==> file://a:./foo
print URI::file->new("foo", "mac");
==> file:/foo
print URI::file->new(":foo", "mac");
==> foo
print URI::file->new("::foo", "mac");
==> ../foo
print URI::file->new(":::foo:bar", "mac");
==> ../../foo/bar
print URI::file->new(":", "mac");
==> ./
print URI::file->new("::", "mac");
==> ../
print URI::file->new("../foo", "mac");
==> file:/..%2Ffoo
print URI::file->new(":..:.", "mac");
==> ../. # buggy currently, should map to %2E%2E/%2E
(I am not 100% sure that the Mac mapping is done correctly yet, but I
guess somebody with Mac experience will tell me if they care :-)
For Win32 ("dos" above) we map both a drive letter and any UNC server
name to the authority component of the URI. This is nice because the
$uri->abs works as it should:
URI::file->new("../../foo")->abs(URI::file->new("a:/foo/")
What we have problem with is representing file names like "a:foo".
This is a relative file name on the A: drive and is not the same as
"a:\foo". It means that we can't map both to "file://a:/foo". The
current private LWP hack is to map the former to "file://a:./foo",
i.e. adding a dot after the colon. I am not sure that is a good idea
though. It is certainly not a good idea to let such URIs escape to
other applications.
On their way back we allow the drive letter to be part of the path
instead of the authority too. We also allow "|" as an alternative to
":". This means that all (that I know of) commonly used dosish
file:-URIs map as they should.
print URI->new("file://a:/foo")->file("dos");
==> A:\foo
print URI->new("file:/a%3a/foo")->file("dos")'
==> A:\foo
print URI->new("file://a|/foo")->file("dos")'
==> A:\foo
print URI->new("file:/a:/foo")->file("dos")'
==> A:\foo
print URI->new("file:/a|/foo")->file("dos")'
==> A:\foo
print URI->new("file:///a|/foo")->file("dos")'
==> A:\foo
print URI->new("file://localhost/a|/foo")->file("dos")'
==> A:\foo
print URI->new("file://server/foo/bar")->file("dos")'
==> \\server\foo\bar
Regards,
Gisle