RE: Status of RFC 1738 -- 'ftp' URI scheme

> From: John Cowan [] On Behalf Of John Cowan
> Sent: Friday, 07 January, 2011 10:16
> Michael Wojcik scripsit:
> > I don't think the file scheme should try to do anything at all,
> beyond
> > attempting to open the named resource using the normal OS mechanism
> > for opening a file.
> But that's precisely my point: UNC names *are* obtained by opening the
> named resource using the normal OS mechanism, given the obvious
> of / to \ (which is not actually required by the Windows kernel).

Hmm. Yes. Good point. That's what I get for posting while distracted.

However, it's only true if the authority portion of the file-scheme URI
is passed to the file-opening mechanism, and it's not clear that is
either the original intent or the desirable behavior of the file scheme.

Certainly *I* would prefer that file-scheme handlers on Windows do
something like the following:

- Convert the authority and path to canonical form if necessary
- Verify that the authority portion is empty or a reference to the local
- Pass the path portion to the standard OS file-opening mechanism
(CreateFile), requesting read access to the data

I explicitly don't want them to treat a file-scheme URI as a UNC name.

But obviously some users (possibly the majority) *would* want a
file-scheme URI treated as a UNC name. And while I might argue that the
principle of least surprise, the principle of least privilege, and a
bias toward security all argue against that, those are arguments that
historically have not had a lot of traction among casual users or
implementors of the software they use.

I suppose what I'm saying, then, is that I don't believe it's clear that
the UNC-mapping behavior is necessarily desirable, and more discussion
on the topic might be called for, if we're trying to standardize the
file scheme.

Michael Wojcik
Principal Software Systems Developer, Micro Focus

This message has been scanned for viruses by MailController -

Received on Friday, 7 January 2011 19:31:04 UTC