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
Related
So I'm recreating a website from web.archive.org. I've downloaded it and it has many pages. The problem is that the past site was a forum php script and now I obviously can't recreate it again. Nevertheless I will be satisfied with only being an html until I build something else.
So the problem now is that there are a lot of files generated from the query urls like this:
index.php#lang=fr
index.php#lang=fr§ion=4
index.php#lang=fr§ion=5
index.php#section=15&fonc=imp&lang=fr
etc...
And when I upload these files to my server the browser threats these no-extension files as text instead of an html, despite the html content inside.
Can anyone tell me why is this happening and is there an easy way to solve it?
EDIT: So apparently is the download software that I used which replaced the original urls ? with #. But if I just bulk rename all files from # to ? they still won't open. So how about the ultimate solution below, how to do that painless and fast?
Ultimately I would like to place each of the old files in one folder and rename them to html and then create htaccess rules from the original URLs to each file respectively in that folder. However doing this manually would take infinite time. So can anyone suggest a simpler solution to this?
This happens because your default content type is likely configured to be text/plain (which is the default in Apache). With HTTP, a resource type is not indicated by a file name extension, it is indicated by the Content-Type response header.
I think that you will have to set the default Content-Type header with this directive in your configuration:
DefaultType text/html
See also: http://httpd.apache.org/docs/2.2/mod/core.html#defaulttype
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.
Well, using HTML5 file handlining api we can read files with the collaboration of inpty type file. What about ready files with pat like
/images/myimage.png
etc??
Any kind of help is appreciated
Yes, if it is chrome! Play with the filesytem you will be able to do that.
The simple answer is; no. When your HTML/CSS/images/JavaScript is downloaded to the client's end you are breaking loose of the server.
Simplistic Flowchart
User requests URL in Browser (for example; www.mydomain.com/index.html)
Server reads and fetches the required file (www.mydomain.com/index.html)
index.html and it's linked resources will be downloaded to the user's browser
The user's Browser will render the HTML page
The user's Browser will only fetch the files that came with the request (images/someimages.png and stuff like scripts/jquery.js)
Explanation
The problem you are facing here is that when HTML is being rendered locally it has no link with the server anymore, thus requesting what /images/ contains file-wise is not logically comparable as it resides on the server.
Work-around
What you can do, but this will neglect the reason of the question, is to make a server-side script in JSP/PHP/ASP/etc. This script will then traverse through the directory you want. In PHP you can do this by using opendir() (http://php.net/opendir).
With a XHR/AJAX call you could request the PHP page to return the directory listing. Easiest way to do this is by using jQuery's $.post() function in combination with JSON.
Caution!
You need to keep in mind that if you use the work-around you will store a link to be visible for everyone to see what's in your online directory you request (for example http://www.mydomain.com/my_image_dirlist.php would then return a stringified list of everything (or less based on certain rules in the server-side script) inside http://www.mydomain.com/images/.
Notes
http://www.html5rocks.com/en/tutorials/file/filesystem/ (seems to work only in Chrome, but would still not be exactly what you want)
If you don't need all files from a folder, but only those files that have been downloaded to your browser's cache in the URL request; you could try to search online for accessing browser cache (downloaded files) of the currently loaded page. Or make something like a DOM-walker and CSS reader (regex?) to see where all file-relations are.
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).
we have a small flash component on our website/application to upload multiple files.
This works fine, however we want to get the Content-Type from the headers and its always set to 'application/octet-stream'. From what I've learned this is due to a security of flash sandbox and FileUpLoad will never give this to us.
Is there any other way we could do this in flash (aside from creating an html/ajax multi file upload)?
many thanks
We have had a simlar problem when uploading from a browser. What is sent in the content type is dependent upon the browser and what is installed on the client machine. If it is an extension that the client machine does not recognise it will come back as application/octet-stream.
What we ended up doing was creating mapping functionality from the file extension to the content type. That way we could ensure consistency.