Workaround for href="file://///..." in Firefox

hmqcnoesy picture hmqcnoesy · Mar 15, 2011 · Viewed 99.2k times · Source

On an intranet site, let's say I want to link to a file on a share using UNC, at:

\\servername\foldername\filename.rtf

It seems the correct way to do this is with markup like this:

<a href="file://///servername/foldername/filename.rtf">filename.rtf</a>

That's five slashes - two for the protocol, one to indicate the root of the file system, then two more to indicate the start of the server name.

This works fine in IE7, but in Firefox 3.6 it will only work if the html is from a local file. I can't get it to work when the file comes from a web server. The link is "dead" - clicking on it does nothing.

Is there a workaround for this in Firefox? Those two browsers should be all I need to worry about for now.

Since this is obviously a feature of Firefox, not a bug, can someone explain what the benefit is to preventing this type of link?

Answer

hmqcnoesy picture hmqcnoesy · Mar 17, 2011

This question has been asked at least twice before, but I was unable to find those posts before posting my own (sorry):

Open a direct file on the hard drive from firefox (file:///)

Firefox Links to local or network pages do not work

Here is a summary of answers from all three posts:

  • Use WebDAV — this is the best solution for me, although much more involved than I had anticipated.
  • Use http:// instead of file:///// — this will serve up a copy of the document that the user cannot edit and save.
  • Edit user.js on the client as described here — this worked for me in Firefox 3.6.15, but without access to client machines, it's not a solution.
  • In Firefox, use about:config, change the Security.fileuri.strict_origin_policy setting to false — this doesn't work for me in 3.6.15. Other users on [SO] have also reported that it doesn't work.
  • Use the locallinks Firefox extension — this sets the Security.fileuri.strict_origin_policy to true for you, and appears to have no other effect.
  • Read the file server-side and send it as the response — this presents the same problem as simply configuring your web server to use http://.