I am supporting a site for a client on the intranet. The site contains links to xml files. These xml files have a unique extension and are intended to be opened by a specific application. Using IE 8, we could support this by setting the option ‘Open files based on content, not file extension’ in Internet Options -> Security -> Custom Level. In IE 9, this option has been removed. Now these files open a new tab and display the xml.
Ideally, I’d like the file to just download through the download manager, but opening file in the application on the client machine would be acceptable as well. What is the best way to do this in IE 9? Is there a setting that I should adjust? Server side, I have tried adjusting the MIME type, but it seems that if I sent it to something unknown (e.g. application/octet-stream) IE determines the content. The last option I could think of would be to adjust the links such that they call an asp.net page that loads the contents of the xml into the response object but changes the header to contain Content-Disposition:"attachment;filename=file.ext”.
Any advice on the best way to solve this problem?
Content-Disposition:attachment is what you are looking for, yes. That is how you instruct browsers to download the file separately, and not try to display it.
You could use routing or rewriting to keep your file URLs, but have an ASHX handle the file so it can set that header. (don't use an ASPX; it's more than you need to just set some headers)
I think the work around that I was looking for was the fact that the 'Open files based on content, not file extension' option in IE8 was renamed, 'Enable MIME Sniffing' in IE9. But Andrew Barber's answer is the correct solution.
Related
CSS files not rendered in IE 9 and 10 but works good in compatibility mode.
I am the following error get "SEC7113: CSS was ignored due to mime type mismatch" in IE 10 .
wherein i don't get a content-type in my response header!
Further this is on my local.
Any suggestions could be appreciated.
It has an answer, summary would be:
As due to MIME type mismatch css was ignored in IE 9 and 10. The MIME type can be correct by utility called File TypesMan It is freeware created by NirSoft. It turned out that the MIME type of .css had been changed to text/plain, preventing IE from rendering my styles. using FileTypesMan to change it back to text/css fixed the problem.
Download FileTypesMan from the NirSoft site. Use the links near the bottom of the page to select the correct version for your operating system (there are different versions for 32-bit, 64-bit, and Windows 98/ME).
Unzip the files to a local folder, and double-click FileTypesMan.exe.
When FileTypesMan has finished listing all file types, scroll down in the top pane to find .css.
Double-click to edit the settings.
Change the value to text/css in the MIME Type field in the dialog box that opens.
Click OK. Job done.
IE 10 should now behave itself (well, at least as far as rendering style sheets is concerned).
Not my work: Its not my own search, you can see this here: https://stackoverflow.com/a/18791928/1762944
I hope this fixed you!
I was wondering that you are not writing type="text/css" but you said, that you are! So I found this the next helpfull article! It has the same issue as yours. SEC7113: CSS was ignored due to mime type mismatch
I just did a simple Google search for the issue, and this was the first result! You should have searched for the issue.
Please ensure that the CSS file gets delivery with the correct "Content-Type" from the server. It must be "text/css". Use the developer console to determine the current type.
Potentially you need to adjust/create the MIME type mapping (e.g. for httpd).
hth
Try to specify the attribute type="text/css" in your tag. Place your style tag in <head> section.
I was having similar problem with an embedded micro-controller (not a lot of control over the server changing content type). Not sure if this applies but I found going into Settings->Compatibility View Settings and adding the IP (site) address the CSS was accepted and the page rendered properly.
Is there a reason that I should not be sending my content-type as binary for everything? I am a bit naive about proper http but it seems to work for everything. What are some of the pitfalls I will run into working this way?
If you send a stylesheet as Content Type binary, IE9 won't render it. It refuses to render any stylesheet that isn't text/css. That's probably enough to keep people from not visiting your site with IE9.
Not to mention the other benefits like the browser handling specific content types differently based on user preferences.
http://blogs.msdn.com/b/ieinternals/archive/2011/03/27/http-406-not-acceptable-php-ie9-standards-mode-accepts-only-text_2f00_css-for-stylesheets.aspx
Edit
Here, you can use this, it will make it easier to determine the content type. The module will have two methods. getExt and getContentType. If you pass the extension to getContentType it will return the Content-Type for that file. I'm not the one that compiled all the content types, unfortunately I forgot where I found it...
https://gist.github.com/976610
If you specify the right content-type, the application/browser requesting the file can handle it properly
For example, if You're downloading a pdf file, the browser knows how to handle the content type "application/pdf" and will open the file directly in the browser, if it doesn't know the type, it will just ask you to download the file
Browser also let you specify a specific program from which you can open a specific type of file, for example, if you download a torrent file, you can tell your browser to open it with uTorrent, and the next time a torrent file is downloaded it will be also opened with uTorrent directly
In Node.js, you can get the content type of a file doing the following:
type = require('mime').lookup(path);
I found out that some websites use css tag like style.css?ver=1. What is this?
What is purpose of ?ver=1?
How do I do it in code?
To avoid caching of CSS.
If the website updates their CSS they update the ver to a higher number, therefore browser is forced to get a new file and not use cached previous version.
Otherwise a browser may get a new HTML code and old CSS and some elements of the website may look broken.
Adding '?ver=1' makes the HTTP request look like a GET query with parameters, and well-behaved browsers (and proxies) will refuse to cache parameterized queries. Of course well-behaved browsers (and proxies) should also pay attention to the 'Cache-control: no-cache', 'Expires', 'Last-Modified', and 'ETag' response headers (all of which were added to HTTP to specify correct caching behavior).
The '?ver=1' method is an expensive way to force behavior when the site developer doesn't know how (or is too lazy) to implement the correct response headers. In particular, it means that every page request is going to force requesting that CSS file, even though, in practice, CSS files change rarely, if at all.
My recommendation? Don't do it.
The purpose of the ?ver=1 is to parameterize the css file, so when they publish a new style.css file they up the version and it forces the client to download the new file, instead of pulling from the cached version.
If you are developing a web application in HTML and CSS or any other technology, and you are using some external CSS or JS files, you might notice one thing that in some cases if you made any changes to your existing .css or .js files then the browsers are not reflecting the changes immediately.
What happens in that case is that the browser do not download a fresh copy of the latest version of the .css and .js files, instead it uses those files stored in your local cache. As a result the changes you made recently are not visible to you.
<link rel="stylesheet" href="style.css?v=1.1">
The above case when you load the web page the browser will treat "style.css" as a different file along with "?v=1.1". Hence the browser is forced to download a fresh copy if the stylesheet or the script file.
I think that ?ver=1 is for the version no. of the web app. Every time a new build is created, the app can update the ver to the new version. This is so that the browser will load the new CSS file and not use the cached one (both use different file names).
You can refer to this site: http://www.knowlegezone.com/36/article/Technology/Software/JavaScript/CSS-Caching-Hack----javascript-as-well
IMO a better way to do this would be to include a hash generated off of the file size or a checksum based on the file contents or last-modified date. That way you don't have to update some version number and just let the number be driven off of the file's changing properties.
Is there any way to open the file explorer setting the filtering options like a desktop application does?, and I don't want to validate the file after is selected, I want my users to view only valid files throught filtering them before.
NO, this is not possible using the asp:FileUpload Control.
How to filter files in file upload control
seems like there is a way using JavaScript.
There is an "accept" attribute which can be set for the upload control however as discussed here, many browsers don't impliment this attribute.
Your best bet is to use Javascript as astander recommends so that you can check the extension of the file being uploaded before it hits the server.
You'll also want to do a check on the server side since client-side validation cannot be relied on for this type of thing.
No, for web applications there is no way yet (Dec 2009) to set the File Selector filtering. According to the INPUT tag (used by the UploadFile control to render) documentation it should be possible by adding the 'accept' attribute and setting the file mime type(s)... so bad that any major browser supports the accept attribute of input tags.
The best workaround is to validate the files on the client and server side.
Is there a built in way to change the favicon for different themes? If not would it be as simple as creatign a custom control to emit the link tag with the correct url to the icon?
Update
So based on what I have found in order to do this, it looks like I am going to have to create an http handler that will intercept all calls for favicon.ico.
This handler will then determine which theme we are using (in my case it will be based on the domain name), it will then output the themed favicon.ico from the various themes folders.
Since I am supporting IE7, I'm thinking this is the only option I have. Still curious if anyone else has a better way.
As long as your user is not using IE, that should be fine. IE (up to at least version 7) only reads the favicon.ico file and completely ignores the link tag.
After some research and thought It looks like the only way to do this and still support IE7 and earlier (I am not sure if IE8 updated support for favicon or not). Would be to dynamically serve the icon to do this you can do the following:
Create and register an HttpHandler to process requests for FavIcon.ico
Configure IIS to send requests for .ico files to ASP.Net (If your using IIS6 or earlier)
Run the logic that you use to determine which theme and from that find the .ico your going to serve up, and send it to the browser.
Note that per W3Schools
http://www.w3schools.com/browsers/browsers_stats.asp
You should expect about 1/2 your users to be using IE.