[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: file://host/location URLs
From: |
Daniel Colascione |
Subject: |
Re: file://host/location URLs |
Date: |
Tue, 20 Nov 2012 12:07:16 -0800 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 |
On 11/20/2012 4:54 AM, Jason Rumney wrote:
> Daniel Colascione <address@hidden> writes:
>
>> Yes, my proposal violates the RFC. I maintain that nobody deliberately
>> constructs file URLs pointing to remote hosts
>
> I do it all the time. Windows has a well defined default protocol for
> accessing remote files on named hosts, and such URLs mostly work (they
> even used to work on Emacs IIRC until url-handler came along and started
> forcing them over to FTP).
Yes, the Windows remote access mechanism is good, party because applications
don't need to be aware of it to use it. They can just use normal filesystem
access APIs. If we treat file URIs as simple filenames, remote access under
Windows will continue to work.
> GNOME, KDE and others may also have mechanisms for dealing with remote
> file URLs that we could use.
All right, let me make a different proposal: by default, we'll treat file://
URIs with non-localhost host parts as errors, since FTP is seldom appropriate.
On Windows and Cygwin systems, we'll treat file://foo/bar/qux as
file:///foo/bar/qux since the underlying OS understands how to access host foo.
If someone wants to integrate Emacs with gnome-vfs, he can update the file-URI
code at that time.
File URI handling seems to be generally broken for local files anyway. Try
(find-file "file://localhost/etc/passwd").
signature.asc
Description: OpenPGP digital signature
Re: file://host/location URLs, Stephen J. Turnbull, 2012/11/18