Our webdesigner has created a CSS with the following font-face:
@font-face {
font-family: \'oxygenregular\';
src: url(\'oxygen-regular-webfont.eot\')
Don't set the Vary Request Header to https
No font loading
Vary:Accept-Encoding,https
Works
Vary:Accept-Encoding
Setting the cache header is necessary to avoid delayed font loading.
I just had the same bug, and for those who want to have a pure solution (non exact-technology related): you need to make sure that the font headers you're sending are not saying no-cache
. On top of what was written before, there are actually two headers which can do it:
"cache-control: no-cache"
and
"pragma: no-cache"
Both of those are saying browser the same, the first one is part of HTTP1.1, the second one is older (HTTP1.0).
Now, solutions:
"cache-control" to "max-age=0"
; you can drop pragma header, it's obsolete (or set it to "pragma: cache"
).no-cache
values, and set proper max-age (e.g. "cache-control: max-age=3600"
- one hour cache). Pragma can be set to "pragma: cache"
or removed completely.Removing the global response NoCache and NoStore settings will fix the fonts, but if you need those settings then obviously that isn't an answer.
My understanding is that only setting the cache to expired will not consistently prevent the display of cached pages; it forces a check to the server but if the page is not modified (304 response) may (usually?) still display the cached version.
(Actually reading this now it has occurred to me that setting client cache to immediately expire in combination with SetNoServerCaching might force the client page to always renew? Seems like it could have performance implications though.)
I have found that in ASP.NET MVC using the OutputCacheAttribute attribute on a controller to disable caching does not break IE fonts.
[OutputCacheAttribute(VaryByParam = "*", Duration = 0, NoStore = true)]
public class FooController : Controller
{
...
}
I realise NoStore is not the same as SetCacheability(HttpCacheability.NoCache) but it seems to work for this purpose.
You could create a base controller with the attribute to inherit from to make the code cleaner.
I found an alternate solution to resolve this issue.
I have embedded the font directly in stylesheet instead of loading as a separate font file. This works absolutely fine in all the browsers including Windows, Mac, IOS, Android etc and help to reduce number of HTTP requests in the webpage.
This will not require any change in header Cache-Control.
@font-face {
font-family: '<FONT NAME>';
src: url(data:application/x-font-woff;charset=utf-8;base64,<BASE64_ENCODED>) format('woff'),
url(data:application/x-font-ttf;charset=utf-8;base64,,<BASE64_ENCODED>) format('truetype');
font-weight: normal;
font-style: normal;
}
You can use built-in base64 command in OS X or Linux for font encoding.
JustAMartin's answer led us to a different solution:
Instead of commenting those last two lines
// do not use any of the following two - they break CSS fonts on IE HttpContext.Current.Response.Cache.SetCacheability(HttpCacheability.NoCache); HttpContext.Current.Response.Cache.SetNoStore();
We added the following line:
HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistory(true);
This should still allow no-cache with the exception of back and forward navigation as I understand it. MSDN - SetAllowResponseInBrowserHistory Method
I found a solution but I cannot see the reason why it works (well, only one reason - it's IE :D).
What I did was to put the same site on Apache and test again. On Apache the fonts worked fine even when using Refresh button. Then in the network inspector I saw that Apache is returning 304 instead of 200 for the eot file and it hit me - so it's caching issue. I went to my ASP.NET app and sure enough - for security reasons (and also to avoid caching AJAX requests) someone had disabled every caching you could imagine:
// prevent caching for security reasons
HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistory(false);
HttpContext.Current.Response.Cache.SetExpires(DateTime.UtcNow.AddDays(-1));
HttpContext.Current.Response.Cache.SetValidUntilExpires(false);
HttpContext.Current.Response.Cache.SetRevalidation(HttpCacheRevalidation.AllCaches);
HttpContext.Current.Response.Cache.SetNoServerCaching();
// do not use any of the following two - they break CSS fonts on IE
HttpContext.Current.Response.Cache.SetCacheability(HttpCacheability.NoCache);
HttpContext.Current.Response.Cache.SetNoStore();
As soon as I commented out the last two lines of code, suddenly fonts started to work without problems on IE. So I guess the answer is: IE cannot load the font if it is not cached. I have no idea why the problem happens only when refreshing/navigating back, though.
Edit - Alternative solution
Instead of commenting those last two lines
// do not use any of the following two - they break CSS fonts on IE HttpContext.Current.Response.Cache.SetCacheability(HttpCacheability.NoCache); HttpContext.Current.Response.Cache.SetNoStore();
Change the SetAllowResponseInBrowserHistory
to true
instead:
HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistory(true);
This should still allow no-cache with the exception of back and forward navigation as I understand it. MSDN - SetAllowResponseInBrowserHistory Method