Issue
Problem:
IE11 does not use my Roboto font-face or my Material Icon font-faces. I’ve narrowed the issue down to the cache-control. When I remove the following from my web.config, IE11 displays my fonts and icons just like any other browser. I found this solution here https://stackoverflow.com/a/37270083/10316412
<add name="Cache-Control" value="no-cache" />
<add name="Pragma" value="no-cache" />
However, I would much prefer not to remove this. Our security scan requires that we have no-cache. We are also not supposed to link to external fonts/icons due to subresource integrity… which is why I have downloaded the fonts and icons into my assets folder.
My Question:
Why does the cache-control affect my fonts not loading? How can I get around this? Can I specify there to be no cache-control headers for just my assets folder?
font-face code for reference:
@font-face {
font-family: "Roboto";
src: url(./assets/fonts/Roboto/Roboto-Regular.ttf);
}
@font-face {
font-family: "Roboto-Light";
src: url(./assets/fonts/Roboto/Roboto-Light.ttf);
}
@font-face {
font-family: "Roboto-Medium";
src: url(./assets/fonts/Roboto/Roboto-Medium.ttf);
}
@font-face {
font-family: "Roboto-Bold";
src: url(./assets/fonts/Roboto/Roboto-Bold.ttf);
}
@font-face {
font-family: "Roboto-Italic";
src: url(./assets/fonts/Roboto/Roboto-Italic.ttf);
}
@font-face {
font-family: "Material Icons";
font-style: normal;
font-weight: 400;
src: url(assets/google-icons/font/MaterialIcons-Regular.eot); /* For IE6-8 */
src: local("Material Icons"), local("MaterialIcons-Regular"),
url(assets/google-icons/font/MaterialIcons-Regular.ttf) format("truetype"),
url(assets/google-icons/font/MaterialIconsOutlined-Regular.otf) format("opentype"),
url(assets/google-icons/font/MaterialIconsRound-Regular.otf) format("opentype"),
url(assets/google-icons/font/MaterialIconsSharp-Regular.otf) format("opentype"),
url(assets/google-icons/font/MaterialIconsTwoTone-Regular.otf) format("opentype");
}
Solution
As mentioned throughout the post, removing cache-control and pragma headers certainly fixes the issue. However I had certain requirements to keep these headers. While I didn’t directly fix this issue, this is how it was resolved for me –
Our application is deployed to an Azure App Service that utilizes Azure Front Door. I believe front door overwrites some of the headers with its own, so when I deployed it to the environment with front door, the issue disappeared altogether.
I should also mention that I did try the <location>
and path
suggestions, but those did not work for me.