Ich habe eine Anwendung mit FontAwesome Glyphe Schriftarten für Symbole, und alles funktioniert gut, wenn ich die Dateien von meinem Server hosten. Wenn ich die CDN-Unterstützung auf meiner Site aktiviere, verhält sich IE 11 ziemlich seltsam in Bezug auf die Font-Dateien. Wenn Sie zu einer Seite navigieren, indem Sie entweder auf einen Link klicken oder eine URL manuell eingeben, werden die Schriftdateien in etwa 95% der Zeit geladen. Wenn ich eine Seite neu lade oder Vorwärts-/Zurück-Schaltflächen verwende (oder ~ 5% der Zeit funktioniert eine normale Seitenladung nicht), IE 11 lädt die erste Schriftartdatei, verliert/lässt den Inhalt des Antwortkörpers irgendwie fallen/ignoriert , versucht, die zweite Datei zu laden, verliert den Inhalt des Response-Body, spülen-spülen-wiederholen, und ich habe keine Font-Glyphen. Alle anderen Browser (einschließlich älterer Versionen von IE) funktionieren einwandfrei.IE 11 lädt keine Ressourcendateien
@font-face Erklärung 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;
}
Normale Seite zu laden:
Zusammenfassung:
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
Antwort-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
Antwortkörper cont ains Schriftdatei.
Auf Seite neu laden:
Zusammenfassung:
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
Kopf Response (für "fontawesome-webfont.eot", die andere sehen gleich aus, mit Ausnahme der Unterschiede in Inhalt-Länge, für die Buchhaltung Unterschiede in der Dateigröße):
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
Antwort Körper ist leer. Beachten Sie, dass die Inhaltslänge in den Details nicht mit dem Wert "received" in der Zusammenfassung übereinstimmt.
Laut CDN-Protokolle und Tracking-Verkehr lokal in Fiddler2 werden die vollständigen Schriftart-Dateien von der CDN bereitgestellt. Soweit ich das beurteilen kann, ist die Antwort vom CDN identisch mit der Antwort von meinem Server.
Aktivieren Caching scheint den Effekt zu beseitigen (zumindest konnte ich es nicht mit Caching aktiviert reproduzieren), aber die Powers That Be sind besorgt, dass dies andere, nicht cachable, Assets in der Anwendung als beeinflussen wird mehr werden auf das CDN übergehen, und daher muss ich die Ursache finden und beheben, anstatt ein Pflaster darauf zu schlagen.
Warum könnte sich IE 11 so verhalten, als hätten die Antworten leere Antwortstellen? Warum behandelt IE 11 eine Antwort von einem CDN anders als eine Antwort vom App-Server, wenn die Dateien und Antwortheader identisch sind?