Re: "file:" URLs?



On 2001.08.20 12:10 Brian Stafford wrote:
> On Mon, 20 August 08:28 Toralf Lund wrote:
> 
> > > why would you want something like that to work ?
> > Because some of us are using GNOME/Linux in a real, networked office
> > environment, with shared disks etc., and are working with LARGE files. 
> 
> >From RFC 1738
> 
> 3.10 FILES
> 
>    The file URL scheme is used to designate files accessible on a
>    particular host computer. This scheme, unlike most other URL schemes,
>    does not designate a resource that is universally accessible over the
>    Internet.
> 
>    A file URL takes the form:
> 
>        file://<host>/<path>
> 
>    where <host> is the fully qualified domain name of the system on
>    which the <path> is accessible, and <path> is a hierarchical
>    directory path of the form <directory>/<directory>/.../<name>.
> 
>    For example, a VMS file
> 
>      DISK$USER:[MY.NOTES]NOTE123456.TXT
> 
>    might become
> 
>      <URL:file://vms.host.edu/disk$user/my/notes/note123456.txt>
> [BS: I corrected a typo in the above example]
> 
>    As a special case, <host> can be the string "localhost" or the empty
>    string; this is interpreted as `the machine from which the URL is
>    being interpreted'.
> 
>    The file URL scheme is unusual in that it does not specify an
>    Internet protocol or access method for such files; as such, its
>    utility in network protocols between hosts is limited.
> 
> My take on this issue.  File URLs referencing localhost, explicitly or
> implicitly, in a message should be regarded as a potential security
> problem
> and disallowed.  I cannot think of any situation where such URLs are
> useful.
> 
> File: URLs containing an explicit host name, on the other hand, are
> potentially
> useful and passed on to a helper program.  The helper program would be
> free to
> choose the access method, e.g. using NFS or SMB to mount the remote file
> system mapping the path name appropriately or mapping the file: URL to
> an appropriate HTTP, FTP or TFTP action to retrieve the content of the
> file.

I don't agree. I think one of the premises of NFS is that the user
shouldn't have to worry about where a file is actually stored.

- Toralf





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]