I have to open a file via a HTML-link.
The file's location is on another computer and adressed by the IP adress (passing through a custom server tool)
EG:
<a href="http://localhost:PORT/FILE.dotx" download>Download</a>
This works in firefox and chrome just fine, but IE (Version 8) interprets the file as a xml-File and tries to open it directly.
There is no possibility to upgrade or change the client's browser.
Is it possible to force IE to download the file without using PHP, VB or Rails?
(as we don't have a apache server or something like this)
lighttpd.conf sample, requires mod_setenv:
$HTTP["url"] =~ "\.pdf\?dl$" {
setenv.add-response-header = ( "Content-Disposition" => "attachment")
}
This is the only reliable way. IE won't trust MIME types because of an old Apache flaw workaround where Apache sent wrong MIME types and Microsoft "fixed it".
While all pdf files could simply be given the downloading header, I have chosen to show a neater way - only the parameter ?dl activates this behavior. Plain pdfs will still display in-browser and only a link which has ?dl appended gets the special treatment.
I am actually using this technique on my server, but it is implemented in php because I can't make do with the static handlers alone. Since I offer images through this, I also add the Cache: no-transform header to prevent Opera Turbo from recompressing the file to be downloaded.
EDIT: Fixed the Disposition word - has to be capitalized to also work in Webkit-based browsers.
Related
I'd like to have an html file that organizes certain files scattered throughout my hard drive. For example, I have two files that I would link to:
C:\Programs\sort.mw
C:\Videos\lecture.mp4
The problem is that I'd like the links to function as a shortcut to the file. I've tried the following:
Link 1
Link 2
... but the first link does nothing and the second link opens the file in Chrome, not VLC.
My questions are:
Is there a way to adjust my HTML to treat the links as shortcuts to the files?
If there isn't a way to adjust the HTML, are there any other ways to neatly link to files scattered throughout the hard drive?
My computer runs Windows 7 and my web browser is Chrome.
You need to use the file:/// protocol (yes, that's three slashes) if you want to link to local files.
Link 1
Link 2
These will never open the file in your local applications automatically. That's for security reasons which I'll cover in the last section. If it opens, it will only ever open in the browser. If your browser can display the file, it will, otherwise it will probably ask you if you want to download the file.
You cannot cross from http(s) to the file protocol
Modern versions of many browsers (e.g. Firefox and Chrome) will refuse to cross from the http(s) protocol to the file protocol to prevent malicious behaviour.
This means a webpage hosted on a website somewhere will never be able to link to files on your hard drive. You'll need to open your webpage locally using the file protocol if you want to do this stuff at all.
Why does it get stuck without file:///?
The first part of a URL is the protocol. A protocol is a few letters, then a colon and two slashes. HTTP:// and FTP:// are valid protocols; C:/ isn't and I'm pretty sure it doesn't even properly resemble one.
C:/ also isn't a valid web address. The browser could assume it's meant to be http://c/ with a blank port specified, but that's going to fail.
Your browser may not assume it's referring to a local file. It has little reason to make that assumption because webpages generally don't try to link to peoples' local files.
So if you want to access local files: tell it to use the file protocol.
Why three slashes?
Because it's part of the File URI scheme. You have the option of specifying a host after the first two slashes. If you skip specifying a host it will just assume you're referring to a file on your own PC. This means file:///C:/etc is a shortcut for file://localhost/C:/etc.
These files will still open in your browser and that is good
Your browser will respond to these files the same way they'd respond to the same file anywhere on the internet. These files will not open in your default file handler (e.g. MS Word or VLC Media Player), and you will not be able to do anything like ask File Explorer to open the file's location.
This is an extremely good thing for your security.
Sites in your browser cannot interact with your operating system very well. If a good site could tell your machine to open lecture.mp4 in VLC.exe, a malicious site could tell it to open virus.bat in CMD.exe. Or it could just tell your machine to run a few Uninstall.exe files or open File Explorer a million times.
This may not be convenient for you, but HTML and browser security weren't really designed for what you're doing. If you want to be able to open lecture.mp4 in VLC.exe consider writing a desktop application instead.
If you are running IIS on your PC you can add the directory that you are trying to reach as a Virtual Directory.
To do this you right-click on your Site in ISS and press "Add Virtual Directory".
Name the virtual folder. Point the virtual folder to your folder location on your local PC.
You also have to supply credentials that has privileges to access the specific folder eg. HOSTNAME\username and password.
After that you can access the file in the virtual folder as any other file on your site.
http://sitename.com/virtual_folder_name/filename.fileextension
By the way, this also works with Chrome that otherwise does not accept the file-protocol file://
Hope this helps someone :)
Janky at best
right click </td>
and then right click, select "copy location" option, and then paste into url.
back to 2017:
use URL.createObjectURL( file ) to create local link to file system that user select;
don't forgot to free memory by using URL.revokeObjectURL()
I've a way and work like this:
<'a href="FOLDER_PATH" target="_explorer.exe">Link Text<'/a>
Up until a few weeks ago, any HTML files I linked to an iFrame would be shown within the frame. All of a sudden, Chrome and Firefox will now ask me whether I want to download the HTML file in the iFrame. It's an Apache server and I do believe it was upgraded recently. How it was upgraded, I am not sure. I was wondering if it had anything to do with the way certain MIME types get processed within an iFrame.
Note: Chrome and Firefox are the only browsers that I've tested this with. I don't think this is a browser issue though.
It's very likely the mime-type configuration is no longer properly set up on your Apache server. Most of the time, the server configuration sets the mime type of the returned object based on the file extension you're requesting. If your file extensions have changed, or if you're using dynamic URLs that don't end in ".docx"), e.g. that get processed by an intervening app server to return the file without themselves setting the MIME type, then the browser has no way of knowing what the contents are, and correctly concludes that the best thing to do is to just gives you the contents in a file.
So... set the extension of the file you're downloading to .docx or .doc. If you're using a default Apache config, that might do it. If that doesn't work, change the mime type of the returned object based on a URL filter configuration in your apache.conf or other apache config file. Or if using dynamic URLs, explicitly set the mime type in your code to one of the following:
.doc - application/msword
.dot - application/msword
.docx - application/vnd.openxmlformats-officedocument.wordprocessingml.document
.dotx - application/vnd.openxmlformats-officedocument.wordprocessingml.template
.docm - application/vnd.ms-word.document.macroEnabled.12
.dotm - application/vnd.ms-word.template.macroEnabled.12
If an image file name does not reflect its correct file type(e.g stored with .pdf extension), is it safe to use it in HTML? Will the browser decide the correct type of the image? Will mobile browsers be able to deduce correct file type?
I have tested it with google chrome, it is working, but Is it guaranteed to run on all reasonable browsers?
UPDATE: I can't rename them to correct extensions, since they will be uploaded by users and then shown again.
Will mobile browsers be able to deduce correct file type?
Browsers don't usually deduce file types (there are exceptions, notably in IE—resulting in text files discussing HTML being treated as HTML and IIS servers sending text/plain content-types for HTML documents without their owners noticing—but they shouldn't be the primary concern).
Instead, browsers determine the type of data by examining the HTTP Content-Type Response header. By default, most servers will set this based on the file extension of the file they are reading from the filesystem to serve to the client.
You can override this, but doing so is fiddly and could cause problems if people save a file before opening it from their local file system (because it will have the wrong extension and their OS will associate it with the wrong application).
Basically, I'm creating a webpage filled with images of movie posters that link to video files, as a means of making a more visually-appealing form of my local video library.
I'm using
<a href="C:\blah\movie.mkv"><img src="poster.jpg">
It works exactly how I want, HOWEVER, it opens the file in the browser rather than opening it in its default program, as I would like. I would like each link to open the file in the program titled "VLC Media Player", as specified in Windows for each of their filetypes.
Let me know how I can do this (in the simplest form--I'm not too smart :P)
Thanks!
If you are creating web pages on your local system for you own use then you may want to consider looking in to a WAMP server setup. This uses php and should allow you to call VLC using the exec command. Would take some learning however.
There is very little you can do to control how a client will handle a resource.
You can use the Content-Disposition HTTP response header to state that the resource is an attachment (and thus recommend that it be downloaded instead of opened).
Content-Disposition: attachment;filename="movie.mkv"
You can't, however, stop browser native support or a plug-in from handling something instead of having it open in a separate application (let alone cause it to be opened in a specific application).
If the browser is configured to open video files internally, then nothing the author of a website can do will make it switch to using a application instead.
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