Talk:File URI scheme

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

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)[reply]

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)[reply]

I believe both are correct. See reasoning below.

The ABNF provided in RFC 8089, Section 2[1] is as follows:

file-hier-part = ( "//" auth-path ) / local-path

– I will point out, that the slash ('/') character denotes optionality in ABNF notation and is not a part of the URI in this example. RFC 5234, section 3.2[2] This makes it clear that if you omit the authority component, you must also omit the double-slash. A triple-slash is also valid. The relevant parts of RFC 3986, section 3.2.2[3] are as follows:

host = IP-literal / IPv4address / reg-name

(...snip...)

reg-name = *( unreserved / pct-encoded / sub-delims )

– The asterisk ('*') in the reg-name part allows for zero repetitions. [4] So a URI of "file:///path" can be seen as a file URI with an auth-path containing an empty reg-name, whereas a URI of "file:/path" is a file uri with a local-path and no auth-path

I hope that this makes it clear that:

  1. "file://path" is not valid
  2. either of "file:/path" or "file:///path" are valid
  3. the RFC's do not contradict themselves.
  4. This wikipedia article is incorrect in stating that "The double slash // should always appear in a file URL according to the specification"

216.113.160.71 (talk) 13:39, 6 July 2017 (UTC) ADK[reply]

References

  1. ^ RFC 8089, Section 2
  2. ^ RFC 5234, section 3.2
  3. ^ RFC 3986, section 3.2.2
  4. ^ RFC 5234, section 3.6

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)[reply]

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)[reply]


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)[reply]


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)[reply]

It's a long time since that discussion, but RFC 8089 Appendix E describes two "non-standard" representations: file://server/folder/file.xml (used by Microsoft .NET) and file:////server/folder/file.xml used by Java. I've updated the article to discuss UNC filenames accordingly. Mhkay (talk) 14:10, 28 August 2019 (UTC)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

References

  1. ^ Kerwin, Matthew. "The 'file' URI Scheme". Internet-Draft Standards Track. IETF. Retrieved 25 February 2014.
RFC 8089 Appendix E mentions both forms and describes both as non-standard. .NET uses one, Java the other. Mhkay (talk) 14:12, 28 August 2019 (UTC)[reply]

About File URI scheme protocol of MAUI wap browser[edit]

Hi, I have a small question here I have some .html, .wml file that I need to test if it work with the MTK phone's MAUI wap browser How to access internal .html or .wml file with MAUI wap browser? What is it exact protocol? Some protocols of other phone basic access like something similar " file:////folder/test.html " to access internal html on phone's storage, but I don't know what MAUI wap browser's function, please help!

Trongducvtc (talk) 16:23, 22 February 2017 (UTC)[reply]

Reference 7 is gone[edit]

It refers to "The Bizarre and Unhappy Story of 'file:' URLs" but the link goes to a site that is dead. A quick internet search does not turn up other copies lying around. However, the link seems to work: https://web.archive.org/web/20130116070556/http://blogs.msdn.com/b/freeassociations/archive/2005/05/19/420059.aspx. I'll update the page to use it.

RossBoylan (talk) 02:49, 24 April 2021 (UTC)[reply]

Open modes?[edit]

The unix file API includes file-open modes: open for reading, for writing, append when writing, truncate to zero length on open. etc. Is there some URI format that can indicate such directives, e.g. open for reading and writing: 

file:rw//host/path

or open for writing and truncate to zero length: 

file:trunc//host/path

or perhaps emulating http GET, so that 

file://host/path?mode=write&access=append

Since this article clearly does not mention this, presumably because its not in the RFC, then perhaps there is some other filesystem URI format that would show this? 67.198.37.16 (talk) 20:00, 19 April 2024 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:File_URI_scheme&oldid=1219783379"