0

The question is, why would IE partially download a resource?

We have an application that uses bootswatch fonts that are not displaying properly in IE 11.0.9600. Upon inspection, IE reports that less data than the entire file's size is being downloaded. Various glyphs and fonts are not being displayed properly, which seems to make sense given the data behind them is never arriving.

In general, these font files are 25KB and up, and internet explorer reports getting an abnormally low amount of data, but with HTTP 200 "all is well".

This is not a general problem with most/all resources, just bootswatch (and also previously fontawesome) resources.

IE network panel reports abnormally low amount of data received

Inspecting the headers reported by IE and by curl (both as curl, and using curl to impersonate IE) indicates that the server seems to be doing everything right. The problem doesn't occur in curl, firefox, or chrome.

headers on response from server

EDIT - further investigation suggested by a user below, I've downloaded and used fiddler, traced the connection - fiddler reports no gzip encoding on this request (meaning that I guess IE's report of 0.65KB is unlikely to be a compressed size). Fiddler reports the correct file size, and saving the response body yields a perfect copy of the right file. All the while fidder is reporting this, IE's network window continues to report 0.65KB of the 25KB file, and the glyphs don't display properly. Any further suggestions on troubleshooting?

FrobberOfBits
  • 17,634
  • 4
  • 52
  • 86

1 Answers1

1

IMHO the content-length reported by IE is the uncompressed one. Try to install fiddler (http://www.telerik.com/download/fiddler) or WireShark if you want to really see what is received. Here's an example of compressed js in both IE and fiddler : https://i.stack.imgur.com/HaOwl.gif

You'll see the compressed size is 649 bytes while the uncompressed is 6662 (maybe that the difference you see).

With fiddler you could save the content and check that your font is well sent. Just right click on the line of the resource and select : Save / response / Response Body and browser where to save the file.

This way you should be sure that nothing alter with this specific files between your IE client and server.

NoobInside
  • 113
  • 7
  • Thanks for this suggestion - I've updated an edit with the result. – FrobberOfBits Jul 09 '15 at 15:55
  • Check-out this link: http://stackoverflow.com/questions/25857942/ie-11-fails-to-load-resource-files ==> http://stackoverflow.com/questions/13415073/on-ie-css-font-face-works-only-when-navigating-through-inner-links. Same symptom. The size you get in IE looks to be the response header size. Only a cache problem? I don't reproduce it on my own after downloading the same woff font. I don't believe in this, but better be sure: since January 2013, correct Mime type for WOFF is application/font-woff, not application/x-font-woff (http://stackoverflow.com/questions/2871655/proper-mime-type-for-fonts). – NoobInside Jul 09 '15 at 19:58
  • Wow - thanks a million. This eventually led me to the right answer with another hour of work. Tl;dr - IE does not load font resources properly if there is no cache lifetime set via HTTP headers. In the case of tomcat, if you write an extra HttpFilter to set a cache lifetime for *.eot, *.ttf, *.woff, the problem goes away. Might I suggest you add this to your answer? But I'll already mark this as answered because it led me the right way. – FrobberOfBits Jul 09 '15 at 21:25