Chrome from version 16 became pretty strict on content-disposition headers having unquoted commas. While most sites out on the web will face user pressure to fix their servers this is not so easy for small or in-house intranet applications that no one is quite willing to touch.
Thread on Chrome's forum about the issue, what works and what doesn't.
Short answer is that the Content-Disposition header, if included, needs to either not have commas in the filename or have filenames quoted.
We have one such system handling document management, touching the codebase is NOT an option, but any files with commas in their names will throw an error in Chrome. how can I fix this?
Doing a bit of a Jeopardy! thing here but not 100% confident on my answer and would appreciate comments/alternatives
You could do this using IIS's URL Rewrite module which can also work on headers.
The key will be to match on Content-Disposition which includes filename= and doesn't have quotemarks for the filename.
<system.webServer>
<rewrite>
<outboundRules>
<rule name="Chrome Comma Fix">
<match serverVariable="RESPONSE_Content_Disposition" pattern="^(.*)(filename=)(?!")([^"]*)(;.*)?$" />
<action type="Rewrite" value="{R:1}{R:2}"{R:3}"{R:4}" />
</rule>
</outboundRules>
</rewrite>
</system.webServer>
I haven't yet tested this though.
Related
I have clients who use HTML on their pages, that I provide. That HTML links to files on my server (JS, CSS, images, etc).Example of what I give them: <link type="text/css" rel="stylesheet" href="http://www.example.org/this.css" />
I just got an SSL, so my site is now https. However the HTML on their server, that I gave them, is still http when requesting files from my server.
Because of this, they are getting mixed content warnings and the content is blocked. Like this:
Mixed Content: The page at 'https://www.example.org/' was loaded over HTTPS, but requested an insecure stylesheet 'http://www.example.org/file.css'. This request has been blocked; the content must be served over HTTPS.
I can't have all of my clients change all of their links on all of their pages to "https" so that warning/blockage is prevented. That would be a nightmare.
My host is GoDaddy. My server is a Windows server, IIS: 7.0, ASP.Net Runtime Version: 4.0/4.5.
How can I resolve this on my end through web.config? My current rules are:
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="HTTP to HTTPS redirect" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTPS}" pattern="off" ignoreCase="true" />
</conditions>
<action type="Redirect" redirectType="Permanent" url="https://{HTTP_HOST}/{R:1}" />
</rule>
</rules>
</rewrite>
</system.webServer>
What I want to happen is have all outside http requests to my https server, to be allowed.
Thanks!
You can serve the site with a Content-Security-Policy: upgrade-insecure-requests header.
The upgrade-insecure-requests CSP directive can also be specified using a meta element:
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
The HTTP Content-Security-Policy (CSP) upgrade-insecure-requests directive instructs user agents to treat all of a site's insecure URLs (those served over HTTP) as though they have been replaced with secure URLs (those served over HTTPS). This directive is intended for web sites with large numbers of insecure legacy URLs that need to be rewritten.
The upgrade-insecure-requests directive is supported in all current browsers.
Incidentally, the “The page at 'https://www.example.org/' was loaded over HTTPS, but requested an insecure stylesheet 'http://www.example.org/file.css'” message is not one that anybody would get by just having a <link…href="http://www.example.org/this.css" /> element in the HTML for their own site. The only way they would get that message is if they navigated directly to https://www.example.org/.
I'm trying to develop a website that uses features not compatible with IE7/8, but the company-standard browser (IE11) we all use forces my page to use Enterprise Mode (which is effectively rendering with IE7/8).
Everything I've seen talks about fixing it on a high-level "site list" within the company, or making a browser not use Enterprise Mode locally (by modifying registry entries). One internally suggested approach was to use the meta tag:
<meta http-equiv="X-UA-Compatible" content="IE=11" />
...but it didn't work.
Is there any way I can force the client, from the server-side, to not use Enterprise mode?
Note: We are using Websphere 8.5 servers.
This has worked for me - forcing the X-UA compatible header from IIS by modifying the application's web.config file as below (if you are using IIS as your webserver).
<system.webServer>
<httpProtocol>
<customHeaders>
<remove name="X-UA-Compatible" /> <!-- in case it was already set -->
<add name="X-UA-Compatible" value="IE=edge" />
</customHeaders>
</httpProtocol>
</system.webServer>
I am trying to get IE to render on the latest version for intranet sites, but it keeps defaulting to IE 7 for compatibility. I have this in my Web.config and it still does not work. A meta tag will not work because this is an intranet site (), and I have tried it, also. I have the following in my web.config:
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="X-UA-Compatible" value="IE=edge" />
</customHeaders>
</httpProtocol>
</system.webServer>
I would appreciate any suggestions. Also, I do know that you can turn off the compatibility mode in IE settings but this would not work for me as I have 1000s of users that would have to do this individually, which would not be ideal and would be my last choice on how to handle the situation.
We have this issue in the organisation that I'm currently working for.
Sorry to be the bearer of bad news but, from what we've discovered, the 'fallback' to IE7 is a network wide policy set by the IT department. As we all know, getting things like this changed is like getting blood from a stone !
Every set-up is different however so you could try this:
<meta http-equiv="X-UA-Compatible" content="IE=Edge" />
Directly after your opening 'head' tag...
I have a new MVC 5 Project and I am trying to get FontAwesome to display icons from the _Layout page. It works fine in Chrome, Firefox, and even the Page Inspector in Visual Studio. When I launch the site in IE 11, it just shows a blank space.
What I've tried so far:
Making sure the font-awesome.css and fonts are being downloaded to the browser
Checking the paths to the directory where the fonts exists is correct
Loading from the BundleConfig and just putting the links directly on the Layout page
Installing FontAwesome using Nuget and tried an Nuget Html Helper for FontAwesome
Tried added MIME types for the fonts to the web.config
Tried using CDNs and Fully qualified paths instead of relative links
Tried several variations of the markup
Validated no errors in the Console or 404s in the Network Debugger
I'm not sure what else I can try and feel like I've spent WAAAY to much time just trying to get some icons to work. It's just frustrating because the site looks really good in Chrome and Firefox.
I am using a Template I downloaded from WrapBootstrap, but their examples work in IE 11, and I've tried to mimick their markup as best I can.
Below is the markup in the Layout page I am using and this comes directly from their Template and it works in FF/Chrome.
<i class="icon-dashboard"></i>
and I tried
<i class="fa fa-dashboard"></i>
Any guidance on troubleshooting would be appreciated.
It's not really that complicated. If it works in Chrome and Firefox it will work in IE11. My guess is that you've either switched the rendering engine to IE7 at some point and forgot, accidentally clicked the compatibility mode button (which renders as IE7), or otherwise are working in compatibility mode (depending on your local or GP settings, if this is a work machine, compatibility mode may be the default for local and/or intranet sites).
I just had this issue but found that it was actually caused by the fact the font files reside on a different subdomain. Adding an Access-Control-Allow-Origin header when serving the fonts solves the problem.
Apache .htaccess snippet
<FilesMatch "\.(ttf|otf|eot|woff)$">
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
</FilesMatch>
nginx virtual host file snippet
location ~* \.(eot|otf|ttf|woff)$ {
add_header Access-Control-Allow-Origin *;
}
More information can be found here (original source for snippets).
Another possibility (which I just spend 4 hours debugging) is that IE-11 is falling back to an older document compatibility mode without your knowledge. The thing to do is make sure the auto-detected target really reads "Edge". In my case it was blank.
The files were downloading.
The MIME types and headers were right.
My document had the right compatibility meta tag set.
I could surf just fine.
The console showed no JS errors (or errors of any kind).
Yet still no Fontawesome.
Turns out if your HD is running low on space as my VM was and the available temp cache falls below a certain size, IE silently reverts to showing all websites in compatibility mode (no matter what your settings are in regard to when to use compatibility mode).
Try this in your web.config. It should work for Font-awesome 4.7:
<system.webServer>
<staticContent>
<remove fileExtension=".svg" />
<remove fileExtension=".eot" />
<remove fileExtension=".woff" />
<remove fileExtension=".woff2" />
<remove fileExtension=".otf" />
<mimeMap fileExtension=".svg" mimeType="image/svg+xml" />
<mimeMap fileExtension=".eot" mimeType="application/vnd.ms-fontobject" />
<mimeMap fileExtension=".woff" mimeType="application/font-woff" />
<mimeMap fileExtension=".woff2" mimeType="font/woff2" />
<mimeMap fileExtension=".otf" mimeType="application/font-sfnt" />
</staticContent>
</system.webServer>
A while ago I designed a app that would insert a meta tag into my pages so I could test them with internet explorer in different document modes. My solution, though functional, was klugy. Assuming IIS7 and explorer as server/client, what are some light weight solutions for quickly adding a meta tag programmaticly for a short time.
You can do that very easily using URL Rewrite and leverage the Outbound Rewrite capabilities. Once it is installed just add a web.config to the application folder like the following and it will automatically insert a META tag to every HTML page that is served by the application. You can obviously add more conditions and make that only rewrite for pages you want (see preConditions) as well as capture data from headers or other places and add it in the response.
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<outboundRules rewriteBeforeCache="true">
<rule name="WriteMETA" preCondition="MatchHTML">
<match pattern="<head>" occurrences="1" />
<action type="Rewrite" value="<head>
<meta name='author' content='Carlos Aguilar Mares' />
" />
</rule>
<preConditions>
<preCondition name="MatchHTML" patternSyntax="Wildcard">
<add input="{RESPONSE_CONTENT_TYPE}" pattern="text/html" />
</preCondition>
</preConditions>
</outboundRules>
</rewrite>
</system.webServer>
</configuration>