3

I thought I have somehow found a solution to the very vexing problem with Firefox and CDN-hosted fonts access, but here comes IE9.

I recently found a very frustrating issue with IE9 caching problem, and chanced upon this blog post (IE9 Redirect Caching Nightmare) which enlightened me more about the actual issue.

I have to admit that I'm not sure whether the above mentioned is actually the issue, but it seems close enough.

Problem:

I have a website set up with 2 domains(base domain and subdomain) pointing to the same server, serving the exact same website which is using a same set of resources from a CDN hosted on Amazon S3, served by Cloudfront.

https://example.com
https://www.example.com

I get these kind of error messages in my IE9 developer tools console when loading fonts from my CSS file using @font-face:

CSS3117: @font-face failed cross-origin request. Resource access is restricted.

This happens when I loaded either of the URL first, then visiting the other second. IE9 is not running in Compatibility Mode. It running is in Document Mode: IE9 Standards.

From my limited understanding of the CORS and the need to set Access-Control-Allow-Origin HTTP header, I have dutifully set it up in S3 CORS policy, and it works perfectly fine with Firefox.

Requests from both domains, will get their respective header when requesting the CDN resource.

It seems that IE9 tried to do some optimization with caching, and cached the redirect too. This causes a problem as the Access-Control-Allow-Origin header is cached as well. Without sending a request to the CDN server, the Access-Control-Allow-Origin header cannot change for different domains.

So I'm left with a situation where the request is from https://www.example.com and yet the Access-Control-Allow-Origin is https://example.com. This leads to the restricted resource problem with the error message above.

Further look: I did a check with Firefox 19, the above situation actually occurs, but it does not encounter the same strict restriction as IE9. Subdomain (https://www.example.com) requesting information will accept the access-control-allow-origin of the main domain(https://example.com). Chrome (Webkit) doesn't seem to care. I'm at a loss about which browser's behaviour implementation is correct.

With my current settings in the CDN, it seems like Chrome and Firefox, automatically reroutes allwww subdomain requests to the main domain. Only upon multiple attempts of inputing the www subdomain in the address bar, then will Chrome and Firefox obey. IE9 on the other hand, just goes to whichever address is typed in the address bar. IE9 seems to be the odd one out here, but I'm not sure which browser's behaviour is actually correct.

From a usability standpoint, Chrome and Firefox seems to be the "correct" behaviour.

Known Possible Solutions:

  1. Set Access-Control-Allow-Origin header to allow all, i.e. *
  2. Turn off caching in the browser
  3. Redirect one domain to the other
  4. Use query string to differentiate different domain calls for resource
  5. Embed the font into the CSS as data-uri

For solution 1, let's just say I'm paranoid that I just want to set specific domains to allow.

For solution 2, is not optimal if I were to set it for all browsers, also my site has to run on mobile devices with usually less-than-desirable download speeds.

For solution 3, possible, but I'm still curious for solution to deal directly with the IE9 caching issue.

For solution 4, it is very hard to implement especially when the resource is called from @font-face. Does it mean that I'll have to dynamically re-generate the CSS for different domain calls for the different line just to load a font to bypass the issue? Seems to defeat the purpose of CSS itself, and caching resources for that matter.

edit: Stylesheet works, font-loading doesn't.

For Solution 5, it is tedious for maintenance and updating, especially when there are changes to the font files periodically.

Question: Are there any known ways to deal specifically with IE9's redirect caching behaviour in this particular case?

Answers and comments are very much appreciated. Thanks in advance!

Edit: More browser test information.

Community
  • 1
  • 1
VKen
  • 4,764
  • 4
  • 28
  • 42

2 Answers2

0

Solution 1: Check this question.

Solution 4: rename your CSS file to style.php and use whatever code you need to call the appropriate resource.

Set the content type at the top of the page.

<?php
    header("Content-type: text/css; charset: UTF-8");
?>

More info about style.php from Chris Coyier.

Community
  • 1
  • 1
Jesse Schoff
  • 700
  • 7
  • 24
  • Thanks for answering, the link to the other question made me look into the problem more closely. Solution 1 is already implemented on the CDN. The issue is with IE9, it seems, as it is the odd one out. I've added more information to my question. Solution 4, I don't use PHP, but I understand the principles to implement. Also, I need the browser to cache the resources for quick page-loading around the website especially mobile clients. Do you know whether dynamically generated stylesheet get cached? Does it bypass the header bypass the header issue? – VKen Mar 13 '13 at 02:02
  • Nope, as stated in the question, I use Amazon web services. – VKen Mar 13 '13 at 04:36
0

We discovered the same weird behavior also in IE10 and IE11.

Resetting the browser cache makes the fonts to be loaded without any problem. Also enabling and disabling compatibility mode.

But when switching to another subdomain, IE does not render the font because request header does not match the response header which is still the URL of the last request. And IE always shows the full URL for even if the definition on the bucket is *.ourdomain.com

So the general issue with allowing cross origin requests to assets like webfonts was solved by adding CORS permissions to the S3 Bucket - that made the webfonts work perfectly in Firefox.

But we still have no idea how to avoid * and tell IE not to cache the response headers.

Stefan
  • 1