Browser Incompatibility with href="file..." [duplicate] - html

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:
filename.rtf
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?

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://.

Browsers like Firefox refuse to open the file:// link when the parent HTML page itself is served using a different protocol like http://.
Your best bet is to configure your webserver to provide the network mapped file as a web resource so that it can be accessed by http:// from the same server instead of by file://.
Since it's unclear which webserver you're using, I can't go in detail as to how to achieve this.

In Firefox to Open File:\\\\\yourFileServer\docs\doc.txt for example you need to turn on some options in Firefox configuration:
user_pref("capability.policy.policynames", "localfilelinks");
user_pref("capability.policy.localfilelinks.sites", "http://yourServer1.companyname.com http://yourServer2.companyname.com");
user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");

As it turns out, I was unaware that Firefox had this limitation/feature. I can sympathize with the feature, as it prevents a user from unwittingly accessing the local file system. Fortunately, there are useful alternatives that can provide a similar user experience while sticking to the HTTP protocol.
One alternative to accessing content via UNC paths is to publish your content using the WebDAV protocol. Some content managements systems, such as MS SharePoint, use WebDAV to provide access to documents and pages. As far as the end-user experience is concerned, it looks and feels just like accessing network files with a UNC path; however, all file interactions are performed over HTTP.
It might require a modest change in your file access philosophy, so I suggest you read about the WebDAV protocol, configuration, and permission management as it relates to your specific server technology.
Here are a few links that may be helpful if you are interested in learning more about configuring and using WebDAV on a few leading HTTP servers:
Apache Module mod_dav
IIS 7.0 WebDAV Extension
Configuring WebDAV Server in IIS 7, 6, 5

Add your own policy, open configuration "about:config" in the location bar and add three new entries:
capability.policy.policynames MyPolicy
capability.policy.MyPolicy.sites http://localhost
capability.policy.MyPolicy.checkloaduri.enabled allAccess
Replace http://localhost with your website.
Works with Firefox 70.0.

I don't know if this will work, but give it a shot! Old article, but potentially still useful.
http://www.techlifeweb.com/firefox/2006/07/how-to-open-file-links-in-firefox-15.html

Related

Browsers Don't Display "Cruftless" links (no index.html for local web dev.)

Found an interesting article about "Cruftless" links (removing the "index.html" from links) but when I do that no browser shows the local pages.
http://www.nimblehost.com/blog/2012/11/why-cruftless-links-are-better/,
This is understandable, it's a 'file' url from a local machine, so what do people do to work on basic html sites offline? How do they preview them?
For example, no browser (understandably) will display this...
file:///JOBS/ABC/About/
... but this is fine...
file:///JOBS/ABC/About/index.html
?... so what do people do to get around this?
The meaning of file: URLs is, by definition, system-dependent. Normally browsers map them to files in the file system in a relatively straightforward manner.
Thus, a link with href value like file:///JOBS/ABC/About/ may or may not work, depending on system. It may fail, or it may open a generated document containing a directory (folder) listing, or it might do something else.
There is normally no need to get around this, and it is pointless to worry about SEO when dealing with local files.
This could, however, matter during site development when you work with a site locally (and perhaps test and demonstrate it locally). Then you might wish to have, say, About us so that it works locally as well as on a server, yielding About/index.html in both cases but without hard-wiring index.html in HTML markup.
I’m afraid the answer is “you can’t”. But as a workaound, you can install and use a local HTTP server, with settings similar to those that you will have on the real server. This means a little extra work (mainly downloading and installing and configuring software like XAMPP), but it also gives you important other benefits, like testing your pages locally with server-based features (to the extent that the real server is similar to the local server).

HTML5 localStorage for offline websites

I'm creating a simple app that a user will download onto his/her computer and then open it with a browser off the harddrive. I need it to be able to store data, using any of the standard browsers. (Although data does not have to be accessible between browsers).
As described by this link, If using HTML5's localstorage, Internet Explorer throws an error if the url of the site is something like file:///C:/Web/mylocaltodo.html. It says it can be gotten round by using 'localhost', but the sample application it provides doesn't how how this would be done.
Is it possible to save data locally for an offline site without the user installing a web server on localhost? And have it work on any modern browser, including Internet Explorer?
Thanks
Although the question is still old, I was facing a similiar problem when creating an application that should synchronize between multiple windows.
So I'd just like to share my experiences with other developers, that may avoid a long search for the problem.
In fact, due to the same origin policy (as for local file access via XMLHttpRequest), access is denied for reading the localStorage, so that changes won't get synchronized between windows.
In short: If you're using file:/// as URL, it won't be able to synchronize the localStorage. Using a simple webserver and http://localhost/ as URL, it will.
Strange behavior and sadly, there is no error message in the javascript console. Keep that in mind when trying out some localStorage experiments offline and don't get crazy searching for the issue in your code ;-)

How can I use a link on an HTML document to link to a shared file through a Novell network?

I am a student programmer working for an IT department at my college, and my most recent project is implementing browser compatibility for a web form my supervisor wrote using HTML and Javascript.
Everything runs fine in IE, Firefox, and Chrome, with the exception of one column. The idea is that the entries in this column are links to files on a shared drive accessible through the college's Novell network. For instance:
724
Anyone accessing this web form from a college computer should hypothetically be able to click the link and have this .doc pulled up from the shared drive. However, this is hit or miss with IE, and doesn't work at all with Firefox or Chrome.
In Firefox and Chrome, I get errors telling me that it is not allowable to load the local resource.
In IE, the link opens a new Explorer window and (sometimes) opens the corresponding Word document.
My prevailing theory is that the way it's currently implemented depends on one of IE's security holes. How could I go about doing this in a way that works without compromising security?
NOTE: I was told that uploading the files to the web server is not an option; they need to stay where they are.
If they have Netware or OES Linux based servers, sharing the files, then ask if NetStorage is available, or else if NoRM (Novell Remote Manager).
Both can make files available over HTTP. NetStorage can provide it over WebDAV and NoRM would be a link to download a file.
Try http://server:8008 for NoRM and http://server/oneNet/NetStorage as likely URL's.

How to easily, transparently, serve gzipped html files to the user's browser?

The user, when he clicks a link, needs to get my compressed html file that his browser will uncompress automatically, without any fuss. What must I do on the server side to accomplish this?
Thanks!
-- ben
I see now from your comment that you're literally trying to get compressed file to open transparently in a browser, not just compress the whole HTTP response.
That is definitely an issue for ServerFault. It relies on two things:
The configuration of your HTTP server (it must be able to determine the appropriate MIME type and tell it to the browser, for most browsers the filename alone is not sufficient).
The browser itself. There's no requirement that browsers be able to transparently open such a file, though many will if given the proper MIME type information.
(Original answer below)
I almost said this belongs on Server Fault, but I think the answer is needed on SO because it's not obvious it belongs on SF unless you understand the mechanisms at work, so:
In most cases, compressing HTTP responses is a capability of web servers, and you or your sysadmin will need to configure the web server (e.g. Apache with mod_deflate) to use that capability.
In the event that your application is its own web server, you need to review RFC 2616 (the HTTP/1.1 spec) and/or the documentation for any framework you're using.
I'm not exactly sure what the right thing is if you're using the webserver like as a reverse proxy... Probably still needs to be in the webserver, if it's possible at all.
What server are you running?
If you have Apache, you can set up mod_deflate

Link to samba shares in html

First off if you're unaware, samba or smb == Windows file sharing, \\computer\share etc.
I have a bunch of different files on a bunch of different computers. It's mostly media and there is quite a bit of it. I'm looking into various ways of consolidating this into something more manageable.
Currently there are a few options I'm looking at, the most insane of which is some kind of samba share indexer that would generate a list of things shared on the various samba servers I tell it about and upload them to a website which could then be searched and browsed.
It's a cheap solution, OK?
Ignoring the fact that the idea is obviously a couple of methods short of a class, do you chaps know of any way to link to samba file shares in html in a cross-browser way? In windows one does \\computer\share, in linux one does smb://computer/share, neither of which work afaik from browsers that aren't also used as file managers (e.g. any browser that isn't Internet Explorer).
Some Clarifications
The computers used to access this website are a mixture of WIndows (XP) and Linux (Ubuntu) with a mixture of browsers (Opera and Firefox).
In linux entering smb://computer/share only seems to work in Nautilus (and presumably Konqueror / Dolphin for you KDE3.5/4 people). It doesn't work in Firefox or Opera (Firefox does nothing, Opera complains the URL is invalid).
I don't have a Windows box handy atm so I'm unsure if \\computer\share works in anything apart from IE (e.g. Firefox / Opera).
If you have a better idea for consolidating a bunch of random samba shares (it certainly can't get much worse than mine ;-)) it's worth knowing that there is no guarantee that any of the servers I would be wanting to index / consolidate would be up at any particular moment. Moreover, I wouldn't want the knowledge of what they have shared lost or hidden just because they weren't available. I would want to know that they share 'foo' but they are currently down.
Hmm, protocol handlers look interesting.
As Mark said, in Windows protocol handlers can be dealt with at the OS level
Protocol handlers can also be done at the browser level (which is preferred, as it is cross platform and doesn't involve installing anything).
Summary of how it works in Firefox
Summary of how it works in Opera
I'd probably just setup Apache on the SAMBA servers and let it serve the files via HTTP. That'd give you a nice autoindex default page too, and you could just wget and concatenate each index for your master list.
A couple of other thoughts:
file://server/share/file is the defacto Windows way of doing it
You can register protocol handlers in Windows, so you could register smb and redirect it to file://. I'd suspect GNOME/KDE/etc. would offer the same.
To make the links work cross platform you could look at the User Agent either in a CGI script or in JavaScript and update your URLs appropriately.
Alternatively, if you want to consolidate SMB shares you could try using Microsoft DFS (which also works with Samba).
You set up a DFS root and tell it about all the other SMB/Samba shares you have in your environment. Clients then connect to the root and see all the shares as if they were hosted on that single root machine; the root silently redirects clients to the correct system when they open a share.
Think of it as like symbolic links or a virtual file system for SMB.
It would solve your browsing problem. I'm not sure if it would solve your searching one.