Font Awesome With HTTPS - css

So I'm experiencing an issue with Font Awesome in IE8 when using HTTPS in my own site and this is even reproducible on Font Awesome's own site. If I go to Font Awesome over HTTPS in IE8 I get boxes for all of the icons however if I go to Font Awesome over HTTP I get the icons rendered correctly.
What is the problem here? I've heard it could be something to do with the relative font paths in Font Awesome over HTTPS but not sure about that.
Here is a screenshot for those who like such things:
Update
So here is the code that references the fonts and loads the CSS. I'm going to use the code from Font Awesome's site since this seems to be an issue with Font Awesome and not
necessarily something with my site:
HTML that references CSS and an icon:
<link rel="stylesheet" href="../assets/css/site.css">
<link rel="stylesheet" href="../assets/css/pygments.css">
<link rel="stylesheet" href="../assets/font-awesome/css/font-awesome.css">
...
<div class="fa-hover col-md-3 col-sm-4">
<i class="fa fa-adjust"></i> fa-adjust
</div>
Within in font-awesome.css:
#font-face {
font-family: 'FontAwesome';
src: url('../fonts/fontawesome-webfont.eot');
src: url('../fonts/fontawesome-webfont.eot?#iefix') format('embedded-opentype'),
url('../fonts/fontawesome-webfont.woff?v=4.0.3') format('woff'),
url('../fonts/fontawesome-webfont.ttf?v=4.0.3') format('truetype'), url('../fonts/fontawesome-webfont.svg?v=4.0.3#fontawesomeregular') format('svg');
font-weight: normal;
font-style: normal;
}

I've determined the issue and will post the answer in case anyone else experiences the same issue. The problem was with the HTTP cache headers we were sending along with the font file. Apparently this causes IE8 over HTTPS to not load the fonts for some reason (if anyone knows the true reason please comment below). The successful headers should look like this:
HTTP/1.1 200 OK
Content-Type: application/vnd.ms-fontobject
Date: Wed, 26 Mar 2014 23:57:04 GMT
ETag: "08b27bc96115c2d24350f0d09e6a9433f"
Last-Modified: Wed, 26 Mar 2014 12:10:02 GMT
Server: Apache-Coyote/1.1
Content-Length: 38205
Connection: keep-alive
but instead were being sent like this:
HTTP/1.1 200 OK
**Cache-Control: max-age=31556926, must-revalidate
Content-Type: application/vnd.ms-fontobject
Date: Wed, 26 Mar 2014 23:58:06 GMT
ETag: "08b27bc96115c2d24350f0d09e6a9433f"
**Expires: Fri, 27 Mar 2015 05:46:52 GMT
Last-Modified: Wed, 26 Mar 2014 12:12:12 GMT
**Pragma: no-cache
Server: Apache-Coyote/1.1
**Set-Cookie: JSESSIONID=844B0798B373A3B8ED54A694C9DFB5C5; Path=/; Secure; HttpOnly
Content-Length: 38205
Connection: keep-alive

This happens in IE only with https.
Remove any HTTP headers from the fontawesome relevant files that prevent caching, e.g.
Expires -1
Pragma: no-cache
After removing the cache control for these files you should see your icons. After reloading your page all the relevant fontawesome files should show HTTP code 304, i.e. the file comes from the browsers cache.

i think the same,
something to do with the relative font paths in Font Awesome over HTTPS

add NoCacheHeaderFilter in web.xml and provide the exclude file paths.
<filter>
<filter-name>NoCacheHeaderFilter</filter-name>
<filter-class>NoCacheHeaderFilter</filter-class>
<init-param>
<param-name>exclude</param-name>
<param-value>^/(image|css|js|fonts|lib|partials)/.*</param-value>
</init-param>
</filter>
add filter like this.
if (null != exclude) {
HttpServletRequest httpRequest = (HttpServletRequest) request;
HttpServletResponse httpResponse = (HttpServletResponse) response;
String context = httpRequest.getContextPath();
String path = httpRequest.getRequestURI().substring(context.length());
if (!exclude.matcher(path).matches()) {
httpResponse.setHeader("Pragma", "no-cache");
httpResponse.setHeader("Cache-Control", "private, max-age=0, no-store, no-cache");
httpResponse.setDateHeader("Expires", System.currentTimeMillis());
}
}
chain.doFilter(request, response);

The practical answer is,using a proxy, to hide to the browser any cache-control and pragma: "no-cache" header returned to the browser.
I used nginx like this, adding the folowing commands the https proxied location:
proxy_hide_header Cache-Control;
proxy_hide_header Pragma;
See here for details.

Related

Asp.net mvc view/page reloaded from browse cache when using browser back button in Safari

I have Asp.net MVC page/view is always fetched from cache when using browser back button. This issue is with safari browser alone and works properly in other browser such as Chrome,Firefox and IE. I went through so many posts which describes similar issues. But till now I am not able find a solution for this .
This is below code from my action method
[OutputCache(Duration = 0, Location = OutputCacheLocation.Any, VaryByParam = "*")]
public ActionResult ABC(string taxonomy)
{
return View()
}
In safari response shows the below
Cache-Control:public, max-age=0, s-maxage=0
Connection:Close
Content-Length:15849
Content-Type:text/html; charset=utf-8
Date:Wed, 12 Nov 2014 06:07:55 GMT
Expires:Wed, 12 Nov 2014 06:07:52 GMT
Last-Modified:Wed, 12 Nov 2014 06:07:52 GMT
Server:ASP.NET Development Server/10.0.0.0
Vary:*
X-AspNet-Version:4.0.30319
X-AspNetMvc-Version:4.0
I have also tried added the bleow code to the action method
[OutputCache(Duration = 0, Location = OutputCacheLocation.Any, VaryByParam = "*")]
public ActionResult ABC(string taxonomy)
{
HttpContext.Response.Cache.SetCacheability(HttpCacheability.NoCache);
HttpContext.Response.AppendHeader("Cache-Control", "private, no-cache, no-store, must-revalidate, max-age=0, proxy-revalidate, s-maxage=0"); // HTTP 1.1.
HttpContext.Response.AppendHeader("Pragma", "no-cache"); // HTTP 1.0.
HttpContext.Response.AppendHeader("Expires", "0"); // Proxies.
HttpContext.Response.AppendHeader("Vary", "*");
}
So the response was like below
Cache-Control:no-cache
Connection:Close
Content-Length:15849
Content-Type:text/html; charset=utf-8
Date:Wed, 12 Nov 2014 06:20:58 GMT
Expires:-1
Pragma:no-cache, no-cache
Server:ASP.NET Development Server/10.0.0.0
X-AspNet-Version:4.0.30319
X-AspNetMvc-Version:4.0
But what ever i do the the safari get's the page from cache when i use the back button of the browser. Kindly help with solution /suggestion to solve this problem .
I had similar problem with Safari and adding onunload="" in body tag and I solved it.
Check: Preventing cache on back-button in Safari 5
I found this alternative approach which solved my problem . Hope this help everyone facing similar issues How do you disable back and forward caching on iOS Safari?

IE 11 fails to load resource files

I have an application employing FontAwesome's glyph fonts for icons, and everything works fine when I host the files from my server. When I enable CDN support on my site, IE 11 behaves rather strangely in regards to the font files. When navigating to a page either via clicking a link or manually entering a URL, the font files load fine ~95% of the time. If I reload a page or use forward/back buttons (or the ~5% of the time a normal page load doesn't work), IE 11 loads the first font file, loses/drops/ignores the contents of the response body somehow, tries to load the second file, loses the contents of the response body, wash-rinse-repeat, and I end up with no font glyphs. All other browsers (including older versions of IE) work fine.
#font-face declaration in CSS:
#font-face {
font-family: 'FontAwesome';
src: url('/common/fonts/fontawesome-webfont.eot');
src: url('/common/fonts/fontawesome-webfont.eot?#iefix') format('embedded-opentype'),
url('/common/fonts/fontawesome-webfont.woff') format('woff'),
url('/common/fonts/fontawesome-webfont.ttf') format('truetype'),
url('/common/fonts/fontawesome-webfont.svg#fontawesomeregular') format('svg');
font-weight: normal;
font-style: normal;
}
Normal page load:
Summary:
URL Protocol Method Result Type Received Taken Initiator Wait Start Request Response‎‎ Cache read‎‎ Gap‎‎
/common/fonts/fontawesome-webfont.eot HTTPS GET 200 application/octet-stream 99.78 KB 109 ms #font-face 2449 0 47 62 0 1420
Response header:
Key Value
Response HTTP/1.1 200 OK
Content-Type application/octet-stream
Last-Modified Mon, 04 Aug 2014 12:49:48 GMT
Accept-Ranges bytes
ETag "07ef492e2afcf1:0"
Server Microsoft-IIS/7.5
P3P CP="NON DSP COR ADM DEV PSA IVA CONi TELi OUR BUS NAV"
Access-Control-Allow-Origin *
Content-Length 101712
Expires Mon, 15 Sep 2014 18:48:40 GMT
Cache-Control max-age=0, no-cache, no-store
Pragma no-cache
Date Mon, 15 Sep 2014 18:48:40 GMT
Connection keep-alive
Response body contains font file.
On page reload:
Summary:
URL Protocol Method Result Type Received Taken Initiator Wait Start Request Response‎‎ Cache read‎‎ Gap‎‎
/common/fonts/fontawesome-webfont.eot HTTPS GET 200 application/octet-stream 462 B 47 ms #font-face 983 0 47 0 0 1248
/common/fonts/fontawesome-webfont.woff HTTPS GET 200 application/x-font-woff 461 B 63 ms #font-face 1092 0 63 0 0 1123
/common/fonts/fontawesome-webfont.ttf HTTPS GET 200 application/octet-stream 462 B 93 ms #font-face 1155 15 78 0 0 1030
Response header (for "fontawesome-webfont.eot", the others look the same, except for differences in content-length, accounting for the differences in file size):
Key Value
Response HTTP/1.1 200 OK
Content-Type application/octet-stream
Last-Modified Mon, 04 Aug 2014 12:49:48 GMT
Accept-Ranges bytes
ETag "07ef492e2afcf1:0"
Server Microsoft-IIS/7.5
P3P CP="NON DSP COR ADM DEV PSA IVA CONi TELi OUR BUS NAV"
Access-Control-Allow-Origin *
Content-Length 101712
Expires Mon, 15 Sep 2014 19:05:13 GMT
Cache-Control max-age=0, no-cache, no-store
Pragma no-cache
Date Mon, 15 Sep 2014 19:05:13 GMT
Connection keep-alive
Response body is empty. Note that content length in the details does not match the "received" value in the summary.
According to CDN logs and tracking traffic locally in Fiddler2, the full font files are being served up by the CDN. As near as I can tell, the response from the CDN is identical to the response from my server.
Enabling caching seems to eliminate the effect (at least, I have not been able to reproduce it with caching enabled), but the Powers That Be are concerned that this will affect other, non-cacheable, assets in the application as more are transitioned over to the CDN, and thus I must find the root cause and fix it rather than slap a band-aid on it.
Why might IE 11 behave as if the responses have empty response bodies? Why might IE 11 treat a response from a CDN differently from a response from the app server, if the files and response headers are the same?
I have been seeing similar issue with the CDN. Am going to update the answer if I find any other solution.
IE has an issue if your font files have no cache set.
I hope this link helps.
On IE CSS font-face works only when navigating through inner links
Update : The issue fixed for me after setting the correct cache control in .htaccess file
I made mine for max-age= 3600 but max-age=0 would work too
<FilesMatch "\.(ttf|otf|eot|woff)$">
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
Header set Cache-Control "max-age=3600"
</IfModule>
</FilesMatch>
MIME types are very important in IE11. You must ensure that the proper MIME types are sent for font files:
application/vnd.ms-fontobject for EOT fonts
application/font-woff for WOFF fonts
What CDN are you using? With the official FontAwesome CDN (http://www.bootstrapcdn.com/#fontawesome_tab), everything should work fine.
For anyone else finding this with the same issue, the following is info, not necessarily a solution.
IE apparently has a bug titled:
#font-face not working with Internet Explorer and HTTP-Header
Pragma=no-cache
They have closed the bug as Won't Fix.
View details here:
http://connect.microsoft.com/IE/feedbackdetail/view/992569/font-face-not-working-with-internet-explorer-and-http-header-pragma-no-cache
I noticed the same issue immediately after adding a few headers to prevent caching, including the pragma header.
So I don't have a good explanantion for why this is failing, but the solution that the one that works, not the one that is ideal. You can burn a good deal of time trying to troubleshoot this and still not get anywhere, there are a ton of variables involved.
Can you set the font fallback to hit your server as opposed to the cdn?
You should be able to specify it in the css that you use one font face, and then another if it fails.
body { font-family:"FontAwesome", "FontAwesomeFallback"; }
Make the FontAwesomeFallback point to your local directory and see if IE11 has the same issue. If it's a CDN issue, hitting your local directories shouldn't be an issue and the font will render properly. If it still fails, it may be an issue with the fontface itself.

IIS font face issue with IE8 eot

I'm having a strange problem with an ASP MVC 4 .Net website using web fonts.
The site references FontAwesome and Roboto, and renders as expected in FireFox, Chrome and IE10, but needs to work in IE8+ as well.
it's worth noting when the html source is saved locally it works in IE8, just not when returned by IIS.
It seems as though the .eot is not being sent to the browser when served up by IIS (7 or debugging in IIS Express in VS2010). But woff and ttf return as expected (confirmed using Fiddler and Firebug).
I already have:
mimeMap fileExtension=".eot" mimeType="application/vnd.ms-fontobject" /> in the web.config.
Build Action set to 'Content' for .css and font files.
css #fontface declared as:
#font-face
{
font-family:'FontAwesome';
src:url('../font/fontawesome-webfont.eot?v=3.1.0');
src:url('../font/fontawesome-webfont.eot?#iefix&v=3.1.0') format('embedded-opentype'),
url('../font/fontawesome-webfont.woff?v=3.1.0') format('woff'),
url('../font/fontawesome-webfont.ttf?v=3.1.0') format('truetype'),
url('../font/fontawesome-webfont.svg#fontawesomeregular?v=3.1.0') format('svg');
font-weight:normal;font-style:normal
}
401:
HTTP/1.1 401 Unauthorized
Content-Type: text/html
Server: Microsoft-IIS/7.5
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
Date: Wed, 16 Oct 2013 14:48:51 GMT
Content-Length: 1293
Proxy-Support: Session-Based-Authentication
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
<title>401 - Unauthorized: Access is denied due to invalid credentials.</title>
<style type="text/css">
<!--
body{margin:0;font-size:.7em;font-family:Verdana, Arial, Helvetica, sans-serif;background:#EEEEEE;}
fieldset{padding:0 15px 10px 15px;}
h1{font-size:2.4em;margin:0;color:#FFF;}
h2{font-size:1.7em;margin:0;color:#CC0000;}
h3{font-size:1.2em;margin:10px 0 0 0;color:#000000;}
#header{width:96%;margin:0 0 0 0;padding:6px 2% 6px 2%;font-family:"trebuchet MS", Verdana, sans-serif;color:#FFF;
background-color:#555555;}
#content{margin:0 0 0 2%;position:relative;}
.content-container{background:#FFF;width:96%;margin-top:8px;padding:10px;position:relative;}
-->
</style>
</head>
<body>
<div id="header"><h1>Server Error</h1></div>
<div id="content">
<div class="content-container"><fieldset>
<h2>401 - Unauthorized: Access is denied due to invalid credentials.</h2>
<h3>You do not have permission to view this directory or page using the credentials that you supplied.</h3>
</fieldset></div>
</div>
</body>
</html>
200:
HTTP/1.1 200 OK
Content-Type: application/vnd.ms-fontobject
Last-Modified: Tue, 13 Aug 2013 10:43:18 GMT
Accept-Ranges: bytes
ETag: "067e7eb1198ce1:0"
Server: Microsoft-IIS/7.5
Persistent-Auth: false
X-Powered-By: ASP.NET
WWW-Authenticate: Negotiate oYGgMIGdoAMKAQChCwYJKoZIgvcSAQICooGIBIGFYIGCBgkqhkiG9xIBAgICAG9zMHGgAwIBBaEDAgEPomUwY6ADAgEXolwEWl1ljYO00B8Uphl5NsfdQu3+5k9yJlSL2JTRqcofSeQ9oylbvSVbHKLWvBrFned5/+Sxodxe6MkY+IB0xEvtp3FVXB4HM3MuanzmqUo7p58L+wDxxG7hdnRgsA==
Date: Wed, 16 Oct 2013 15:36:17 GMT
Content-Length: 29360
�r���q����������������������LP�����������������������#M
�������������������F�o�n�t�A�w�e�s�o�m�e����R�e�g�u�l�a�r���$�V�e�r�s�i�o�n� �3�.�1�.�0� �2�0�1�3���&�F�o�n�t�A�w�e�s�o�m�e� �R�e�g�u�l�a�r�����BSGP�������������������q��q��e�����Y�D
M�F�x���>��ޝ��Ə)[1ɵH���-A)F��ٜ1��.�/
d�U'�&a

Download link to RDP file in IE9

I have a website containing a link to an RDP file. When the user clicks the link, the file should be offered as a download. It works with every browser, also in IE9 on localhost. But online, IE9 does not recognize the file type and the file name, and clicking on save causes an error. Did I forget a correct header? Or are there some trusted site settings I have to change since it works on localhost?
I get the following headers when accessing the rdp file:
Date: Mon, 19 Dec 2011 12:58:50 GMT
Content-Disposition: attachment; filename="Demo_WIN.rdp"
Content-Type: application/octet-stream;charset=UTF-8
Content-Length: 72
Keep-Alive: timeout=15, max=46
Connection: Keep-Alive
username:s:Tester431
full address:s:176.1.2.3
domain:s:MYRDP
I think you need to set the content type to "application/rdp". Here are the relevant headers I use, which work on every browser I've tried, including IE9:
Content-Type: application/rdp; charset=utf-8
Content-Disposition: attachment; filename=Application.rdp

Google Chrome Developer tools - CSS file showing as an image resource

I'm running the beta of Google Chrome (12.0.742.60)
My page displays fine, however for some reason, in the Developer Tools 'Resources' tab, it's CSS file is shown under the 'Images' disclosure triangle instead of 'Stylesheets' (where the typekit.com CSS is as expected.) Grateful for any ideas..
CSS tag:
<link rel="stylesheet" type="text/css" href="/styles/lofkch.css" />
CSS response headers (via 'Web Developer' extension):
Date: Sat, 21 May 2011 18:52:30 GMT
Content-Length: 9218
Last-Modified: Sat, 21 May 2011 18:40:50 GMT
Server: Apache
ETag: "5ff9-2402-4a3cd93cab080"
Content-Type: text/css
Accept-Ranges: bytes
200 OK
Live page - REMOVED - see answer for cause.
Aside: There was an excellent Google IO session on the new features in GDT earlier this month.
What happens if you remove the empty background-image?

Resources