I'm dynamically generating a text file in PHP, so it has a .php extension but a text/plain MIME type. All browsers display the file as nicely preformatted text, except IE8.
Googling tells me that they've added security where if the HTTP header content type doesn't match the expected content type (I think based on the extension and some sniffing) then it forces the file to be downloaded. In my case I have to open it, and also give it permission to open the file I just told it open! That's probably a Win7 annoyance though. Serving a static plain text file works fine, of course.
So can I stop IE8 from downloading the file and get it to view it normally? The code has to run on multiple shared hosting environments, so I think I'm stuck with the .php extension.
Add this to your HTTP header:
X-Content-Type-Options: nosniff
It's an IE8 feature to opt-out of its MIME-sniffing.
Source
Alternatively, you can "trick" IE8 into thinking that it is indeed serving up a text file. These 2 lines do it for me and don't involve using non-standardized "X-" headers:
Header("Content-Type: text/plain");
Header("Content-Disposition: inline; filename=\"whatever.txt\"");
Related
I have the below code in the controller.
The parameters base64String, fileName are being sent from the browser.
var fileContent = Convert.FromBase64String(base64String);
return File(fileContent, contentType, fileName);
How do I address the XSS threat here?
The above code is based on a fix recommended here
Kendo UI Grid Export to Excel / PDF not working on IE9
I'm assuming you are not returning HTML to your users (you are returning PDFs or Excel files, or something else for download by the browser instead of for render).
The general guidelines are as follows:
Set the correct Content-Type header.
Set the following response header: X-Content-Type-Options: nosniff. Browsers such as Internet Explorer will try and auto detect the content type and ignore the one you've just set.
Set the Content-Disposition header so the browser downloads the file rather than displaying it: Content-Disposition: attachment; filename="bar.pdf"
Following the above should ensure that any script code contained in the file is not executed by your browser. Be aware that IE (again!) can sometimes process script in XML files, so you should test for this.
I am not able to get compressed html pages in my browser even though I am 100% sure mod_deflate is activated on my server.
My htaccess file has this code snippet :
<IfModule mod_deflate.c>
<Files *.html>
SetOutputFilter DEFLATE
</Files>
</IfModule>
A non compressed excerpt of my content is:
<div>
<div>
Content
</div>
</div>
With the htaccess code I am using, I would expect to get the output below in my browser (no space and no tabs at the beginning of each line):
<div>
<div>
Content
</div>
</div>
Is there something wrong with the code I am using in the htaccess file?
Is keeping all tabs in front of each html line after compression the normal behavior of mod_deflate?
If so, would you recommend that I switch tabs with spaces in my html code to get the desired effect?
Thanks for your insights on this
For the Deflate output filter to compress the content
Your content should be at least 120 bytes; compressing lesser bytes increases the output size.
The http client making the request should support gzip/deflate encoding.
Most modern Web browsers support gzip encoding and automatically decompress the gziped content for you. So what you are seeing using a Web browser's View Page Source option is not the compressed content. To verify if your browser received a compressed content, hit the F12 Key, select the Network tab and your requested page. If the response header has Content-Encoding: gzip, you can be sure the compression worked.
In Firefox, you can remove support for gzip,deflate by going to about:config and emptying the value for network.http.accept-encoding. Now with no support for gzip, Firefox will receive uncompressed content from your Apache server.
Alternatively, if you want to see the compressed content, you can use a client that does not automatically decompress the contents for you (unless you use --compressed option).
You can use curl for this:
curl -H "Accept-Encoding: gzip,deflate" http://example.com/page.html > page.gz
I'm sending the HTTP header "Content-type: application/atom+xml; charset=utf-8" in my Atom 2.0 feed right now (using the header() function in PHP).
Whenever I open the URL in Chrome or Konqueror, it will just show text.
If I change that to application/xml, Chrome will display an XML tree and Konqueror will still display that as text.
Since I have an Agregator on my computer, shouldn't that xml be opened with it?
And if not, since these standards have more than 10 years, shouldn't these browser at least put a button on top of the page to invite downloading an Agregator?
Because of these 2 reasons I guess I'm not using the proper content-type. What do you think?
That's the correct Content-Type for an Atom feed (application/atom+xml). However, Chromium does not handle it correctly (Issue 104358: RSS feeds are not parsed correctly).
One possible workaround for Chromium's bug is to use a more general type (e.g., application/xml). Alternatively, stick with the correct type and accept that users who have chosen that browser will get a more confusing experience.
What is the htacces equivalent to meta http-equiv="Content-Type" content="text/html; charset=utf-8"? Yslow says i should put this in my htacces. I'm on appache server.
Ok seen here I have I think an answer. Which code is appropriate though? I only have html extensions on my site. http://www.askapache.com/htaccess/setting-charset-in-htaccess.html
AddCharset UTF-8 .html
vs
AddType 'text/html; charset=UTF-8' html
vs
AddDefaultCharset UTF-8
vs
Content-Type: text/html; charset=UTF-8
The first one, AddCharset, tells the server that files ending in .html should be said to be encoded in UTF-8.
The second gives the full Content-Type for HTML files, including both the MIME type and charset. This shouldn't be necessary, since Apache should already be configured to serve .html files as text/html.
The third, AddDefaultCharset, sets the default character set for all file types, not just HTML. So, for instance, text documents, XML documents, stylesheets, and the like will be served with a UTF-8 character set listed. This is what I would recommend; you should be saving all of your documents in UTF-8 by default anyhow, and so even if all of your documents are HTML now, this will keep the correct character set configured for other types of files if you add them later.
The last is not an Apache configuration; it's the actual header that should be sent along with your documents if you set one of the above options. You can check the headers that were sent in Firebug on Firefox, or various developer tools that other browsers offer. You should always have a Content-Type: header, and if your text is encoded in UTF-8, it should always specify charset=UTF-8.
Note that the meta tag is not required if you set the charset appropriately via the headers. It is still nice to have the meta tag if you are going to view the files locally, without a web server; in that case, there is nothing to set the header, so the browser needs to fall back toe the meta tag. But for this purpose, you can use the shorter and simpler meta tag: <meta charset=utf-8>. This abbreviated form was formally introduced in HTML5, but browsers have actually supported it for much longer, and it's compatible with all modern browsers, even back to IE 6.
Another possibility is the rewrite engine (in this case, matching no-extension URLs):
RewriteEngine on
RewriteRule ^([^.]*)$ $1 [type=text/html]
Heey all,
I have a problem with my custom 404 page.
domain.com/lalala -> displays the 404 page in plain text
domain.com/lalala.html -> displays the page correctly
The problem is not present in Internet Explorer, but only in Firefox/Chrome.
I think this all has something to do with mime types. I tried add a mime type rule:
.* -> text/html but no result.
By the way, it hosts a sharepoint 2007 site.
Anyone suggestions?
Tnx
I did some poking around for you, and the consensus seems to be that this is caused in Sharepoint by invalid and invisible characters in the default Sharepoint 404 file. The solution seems to be to recreate a 404 page from scratch (don't copy/paste), overwrite, and try again.
IE is generally more forgiving about the content-type header than FF or Chrome, so I'm not surprised it works there.