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

> From: John Cowan [mailto:cowan@ccil.org] 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
mapping
> 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
host
- 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 - www.MailController.altohiway.com

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