Last modified: 2010-05-15 15:29:25 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 614 - file URI s do not work (even after patch in Parser.php)
file URI s do not work (even after patch in Parser.php)
Product: MediaWiki
Classification: Unclassified
Redirects (Other open bugs)
PC Windows XP
: Highest normal (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2004-10-01 06:49 UTC by T. Gries
Modified: 2010-05-15 15:29 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description T. Gries 2004-10-01 06:49:56 UTC
According to
 describing a patch in Parser.php it should be easily possible to allow file://

I tried this, but it is not possible fo me, as the link appears to be not
correctly rendered (tagged), no matter, if I embbed the file:// into [ ] or not.
Comment 1 Brion Vibber 2004-10-01 06:53:55 UTC
Can you please provide the actual wikitext tried, and an exact diff showing your change to the code? Make sure also that this isn't simply a cached 
page issue.
Comment 2 T. Gries 2004-10-01 07:12:30 UTC



The patch as described here
Link to local files] 
--[[User:WikiAdmin|Thomas Gries]] 08:46, 1 Oct 2004 (CEST)

Comment 3 Brion Vibber 2004-10-01 07:24:57 UTC
The URL "file:///D:/Homepage/tg/40.html" seems to work fine here. (Internet Explorer 6 on Windows XP SP2.) The other two are invalid as they use 
backslashes, so they cut off at the drive letter.
Comment 4 T. Gries 2004-10-01 07:55:50 UTC

it is not working (WinXP SP2, neither Netscape 7.1 or IE6.0 do).

The behaviour is as follows:

- The Link is shown in the status line, i.e. the browser _could_ get the URI,
but the double-click does _not_ perform opening the file.
- remaining link of _the_ page (see my bugzilla posting 07:12 UTC)
"[http://meta.wikipedia ...." is (patch applied) not rendered as a link, but
with escaped(!) characters:

(cut&paste from my screen:)

... file:.2F.2Flocalhost.2FC:_C-Drive.5D_.3F' class='external'
title=" it somehow possible to use a
FILE URI-Qualifier for local intranets e.g. .5Bfile:.2F.2Flocalhost.2FC:
C-Drive.5D .3F">Link to local files

- I shall supply you with screenshots (a half day later).
- Could be a problem o fhe "class" and "text" tags in the <a href anchors ?

It seems to be a strange error. As written above, XP2, IE6.0 and NETSCAPE 7.1
are affected.
Comment 5 Brion Vibber 2004-10-01 08:24:47 UTC
Before you go any further, please test that your browsers support using file: links from an http: source. This may be disabled by default due to 
general security issues with file: URLs and malicious scripting vulnerabilities.

I've been unable to get any of these working in raw HTML served via HTTP:
<p><a href="file:///c:\foo.htm">a</a></p>

<p><a href="file:///c:/foo.htm">b</a></p>

<p><a href="file:///c|/foo.htm">c</a></p>

All the URLs work when pasted into the URL bar in both IE6 and Firefox 1.0PR, but clicking has no effect in either browser when the source file is 
served via HTTP from my test server. When the file is saved to disk and loaded, all links work in both browsers.
Comment 6 T. Gries 2004-10-01 08:53:09 UTC

I can *confirm* your findings regarding your statement, that the file:/// links appear to work only for accessing files from a 
locally saved html file what I *only* tested before launching the #614 .

However, when I set in my IE6.0 (now on Windows2000) the security setting "Miscellaneous -> Access data source across domains = 
enable" (I am not sure, if this one influences the file:/// behaviour), and after restarting IE:

nothing has changed.

I also need to investigate the other reported problem (a further non-file link on that page is not-rendered as link and escaped). 
So please keep the bugreport open - I'll try to locate both reasons and to better show with screenshots, what is or what is not 
going wrong, and: from a fresh installation of perhaps the recent 1.3.5 (my bug report is related to 1.3.2 as correctly indicated).
Comment 7 T. Gries 2004-10-02 18:47:12 UTC
Does anyone know, why three slashes are needed ? Isn't that another (small) bug
? Tom

By the way, I clarified the item of FILE-URIs on Meta-FAQ (full link: see in the
bug posting), as every major current Windows browser seems to suppress
delivery/linking of local files, if the file:// link resides on a
server-delivered html page. (Only file:// links on locally saved html pages are
treated by most browser.)

I came to the conclusion, that no reason exists why file:// links should be
enabled in a wiki software: the wiki user would need to save the rendered page
as html file locally, until he/she could use file:// links pointing to another
local stored file.
Comment 8 T. Gries 2004-10-02 18:49:56 UTC
I changed the bug status to RESOLVED / WONTFIX, as the non-working of such
file:// links cannot be influenced by changes of the wiki software, as it
depends only on the client's browser.
Comment 9 Phlip 2005-05-21 12:40:13 UTC
> Does anyone know, why three slashes are needed ? Isn't that another (small) bug ?

The definition of a URL with a path is protocol://host/path (plus some other
stuff, but that's the simple form)
Technically file urls should be file://localhost/path but this is usually
abbreviated as file:///path (ie no host) since localhost is the only computer
you'd want to use file: for anyway.
Most browsers will accept file://localhost/path (tested in IE and Mozilla,
Mozilla also accepts file://anyhostname/path and treats it as localhost but IE
will only accept "localhost" - not even "" will work)

Note You need to log in before you can comment on or make changes to this bug.