Talk:File URI scheme

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing  
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 ???  This article has not yet received a rating on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
 

Which RFC?[edit]

The article says:

The double slash // should always appear in a file URL according to the specification

As I understand it, RFC 2396 in 1998 removed the requirement for the double-slash (sec 3 (p10) made the 'net_path' component, including the slashes, optional); and the current specification (since 2005) is RFC 3986 which says (sec 3.2.2, p.15):

When authority is present, the path must either be empty or begin with a slash ("/") character. When authority is not present, the path cannot begin with two slash characters ("//").

which is a little confusing (what about 3 slashes?) but seems to say that a leading double-slash is not allowed at all for file URIs without a host.

Since a lot of eyes have usually gone over wikipedia definitions already I suspect I've misread the RFCs somehow, but if I haven't a lot of this article is wrong Marinheiro (talk) 15:13, 12 June 2013 (UTC)

I've just read the current Javadocs for the URI class; these imply that RFC3986 contradicts itself:

An empty authority component is permitted as long as it is followed by a non-empty path, a query component, or a fragment component. This allows the parsing of URIs such as "file:///foo/bar", which seems to be the intent of RFC 2396 although the grammar does not permit it.

In spite of that statement, the default output from java File.toURI() is file:/filename, not file:///filename Marinheiro (talk) 15:49, 12 June 2013 (UTC)

Opera[edit]

"No modern browsers replicate this ability."

Opera's "View source" opens file in built-in text editor that saves modified pages to disk. Does that count?

And what about Amaya? -- The lynx browser, found on just about every linux system, also has the (e)dit command that is available when a file:// url is selected. —Preceding unsigned comment added by 192.16.167.150 (talk) 18:01, 21 November 2008 (UTC)

Network shares[edit]

The bit that says "For network shares, add an additional two slashes. For example, \\host\share\dir\file.txt, becomes file:////host/share/dir/file.txt." sounds very dubious to me, and I've tagged it as needing a citation. According to the RFCs, a path with a host name should be preceded by two slashes, not four. Of course, it's possible that Windows has gone its own way here again; unfortunately, I don't have access to a Windows system with network shares right now so that I could test it.

Also, the remainder of that paragraph and the one following it are copied almost verbatim from http://www.cs.tut.fi/~jkorpela/fileurl.html and should be rewritten. —Ilmari Karonen (talk) 02:22, 16 December 2008 (UTC)


Regarding the network shares, four slashes can be used, but it's generally either two or five. The URL is file://(host)/(path). Often you are referring to the local host, so this can be file://localhost/ aka file:///. If the browser knows how to talk to that server (unusual; needs to assume server's protocols), the path can be file://server/path, which is what you're discussing. If the browser needs to relay the request to the local system, the path would be file://localhost///server/path (from file://localhost/\\server\path), or, simplified, file://///server/path (five slashes). Of course, if it's a mount point, you don't specify the share at all: file:///mnt/share/path. Internet Explorer on Windows will assume CIFS for file://server/ URLs while Firefox and other browsers assume that file://server/ is unreachable. RFC 1630, page 19, says:

There is clearly a danger of confusion that a link made to a local

file should be followed by someone on a different system, with unexpected and possibly harmful results. Therefore, the convention is that even a "file" URL is provided with a host part. This allows a client on another system to know that it cannot access the file system, or perhaps to use some other local mecahnism to access the file.

205.154.237.150 (talk) 02:13, 15 May 2009 (UTC)


I came accross this page because I was having this same doubt. Especially after trying to make such links work on different browsers:

  • Opera will only recognize file://server/path . If four or five slashes are used it will automatically insert 'localhost' and 'c:' resulting in file://localhost/c://server/path which obviously fails...
  • Firefox will only accept file://///server/path. Interestingly enough, it will also accept file://localhost///server/path which makes no sense at all to me... but works
  • IE will accept both file://server/path, file:////server/path and file://///server/path

I've been looking across the web and couldn't find a proper specification defending either way. Which is probably why browsers have gone separate ways. Personally, I'm more inclined to agree with the 2 slashes only version. But I think the article should be changed to reflect such a disparity of behaviors, instead of stating that four slashes should be used (which, as stated, didn't work in most places).Pauloaguia (talk) 13:37, 16 October 2009 (UTC)

Confusing[edit]

I'm using Window XP SP3 with Internet Explorer 7 and Mozilla Firefox. As I had some problems with the "file:" syntax I tried to find some decent documentation. I couldn't! The Automatic configuration address in the Internet Explorer 7 works with file://c:/download/proxy.pac but not with file:///c:/download/proxy.pac which is the syntax described here. Replacing "c:" with "c|" also never worked! I have a link "file:////proxypac.example.net/web/proxy.pac" that works in IE, but in Firefox I have to add another slash: "file://///proxypac.example.net/web/proxy.pac". When I asked someone for the reference link for our proxy.pac he even send me a link containing backslashes instead of slashes!

So the syntax described here didn't work for me and the working solutions are missing from the documentation SixtiEight (talk) 09:32, 20 July 2009 (UTC)

What about ... file:/path/to/file[edit]

http://www.faqs.org/rfcs/rfc3986.html indicates the authority section is not necessary. The authority section is typically a host name, etc.

If the authority section is not available or not necessary, then simply omit it.

In the case of a file URL this is often the case. There is not authority for the file (it is just part of the filesystem), the authority should be omitted, leaving a simple URL with no '//authority' section. For example, the file /etc/hosts has the file URL file:/etc/hosts

Similarly, the file C:\Windows\notepad.exe has the URL file:/C:/Windows/notepad.exe

The reason I question this is because Java's File class produces URI's without the double // authority. File.toURI()

Similarly, 'curl' accepts simple file URL's without an authority section.

curl file:/etc/hosts

The base wiki page for file URL does not even mention this possiblity of having a simple path-only URL(no authority), and yet it is what should in fact be the only way of doing it. Other ways are 'broken'.

On that note, when is it possible to use the file: scheme to actually access a file on some remote host? As a URI maybe, but not a URL.... — Preceding unsigned comment added by 99.250.163.4 (talk) 15:02, 6 September 2011 (UTC)

+1. Here is some discussion on this topic. --Cebus (talk) 21:12, 18 December 2011 (UTC)

The 'file' URI Scheme: draft RFC[edit]

I made some edits yesterday here regarding the drive letter colon in file URIs that refer to Microsoft computers. While I was searching the refs, I was surprised at the lack of clarity to be found. Today I looked some more and found this draft RFC. It looks like a fast-moving target, with about two version releases a month, and I have no idea of its status (for example is it the only current draft on this topic or are there other competing ones?). Nonetheless, it appears to be extremely relevant.

For the record, what it currently says on drive letters is that the following SHOULD all work in exactly the same way.

     file:///c:/TMP/test.txt
     file:///c|/TMP/test.txt
     file:///c/TMP/test.txt

I think it may be too early to include this as an article citation, being a draft document only published two days ago, but it is an attempt to clarify. --Nigelj (talk) 11:09, 1 August 2013 (UTC)

Internet Draft update[edit]

https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme will get you the latest draft. An "Internet Draft" is a step on the way to RFC, but not called a "draft RFC". The IETF Applications Area working group has accepted this document as a "work item" so that means there's some commitment to complete and publish the document as a standard. Please review and send comments.


Masinter (talk) 11:36, 30 January 2015 (UTC)

UNC documentation is wrong[edit]

The content of this article is mostly wrong.

If people want to reference a modern standard, could they at least reference the current draft[1]?

2.2.  Syntax
      fileURI       = "file" ":" ( auth-file / local-file )
      auth-file     = "//" ( host-file / nohost-file )
      nohost-file   = path-abs       ; begins with "/"
                                     ;   file:////<UNC-path>
      path-abs      = 1*( "/" segment )

According to this, it's pretty clear that the proper UNC syntax is: file:////unc-server/unc-share/unc-path/unc-file and not something else (certainly not file://unc-server/unc-share).

208.65.73.208 (talk) 17:39, 25 February 2014 (UTC)

  1. ^ Kerwin, Matthew. "The 'file' URI Scheme". Internet-Draft Standards Track. IETF. Retrieved 25 February 2014.