IIS font face issue with IE8 eot - css

I'm having a strange problem with an ASP MVC 4 .Net website using web fonts.
The site references FontAwesome and Roboto, and renders as expected in FireFox, Chrome and IE10, but needs to work in IE8+ as well.
it's worth noting when the html source is saved locally it works in IE8, just not when returned by IIS.
It seems as though the .eot is not being sent to the browser when served up by IIS (7 or debugging in IIS Express in VS2010). But woff and ttf return as expected (confirmed using Fiddler and Firebug).
I already have:
mimeMap fileExtension=".eot" mimeType="application/vnd.ms-fontobject" /> in the web.config.
Build Action set to 'Content' for .css and font files.
css #fontface declared as:
#font-face
{
font-family:'FontAwesome';
src:url('../font/fontawesome-webfont.eot?v=3.1.0');
src:url('../font/fontawesome-webfont.eot?#iefix&v=3.1.0') format('embedded-opentype'),
url('../font/fontawesome-webfont.woff?v=3.1.0') format('woff'),
url('../font/fontawesome-webfont.ttf?v=3.1.0') format('truetype'),
url('../font/fontawesome-webfont.svg#fontawesomeregular?v=3.1.0') format('svg');
font-weight:normal;font-style:normal
}
401:
HTTP/1.1 401 Unauthorized
Content-Type: text/html
Server: Microsoft-IIS/7.5
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
Date: Wed, 16 Oct 2013 14:48:51 GMT
Content-Length: 1293
Proxy-Support: Session-Based-Authentication
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
<title>401 - Unauthorized: Access is denied due to invalid credentials.</title>
<style type="text/css">
<!--
body{margin:0;font-size:.7em;font-family:Verdana, Arial, Helvetica, sans-serif;background:#EEEEEE;}
fieldset{padding:0 15px 10px 15px;}
h1{font-size:2.4em;margin:0;color:#FFF;}
h2{font-size:1.7em;margin:0;color:#CC0000;}
h3{font-size:1.2em;margin:10px 0 0 0;color:#000000;}
#header{width:96%;margin:0 0 0 0;padding:6px 2% 6px 2%;font-family:"trebuchet MS", Verdana, sans-serif;color:#FFF;
background-color:#555555;}
#content{margin:0 0 0 2%;position:relative;}
.content-container{background:#FFF;width:96%;margin-top:8px;padding:10px;position:relative;}
-->
</style>
</head>
<body>
<div id="header"><h1>Server Error</h1></div>
<div id="content">
<div class="content-container"><fieldset>
<h2>401 - Unauthorized: Access is denied due to invalid credentials.</h2>
<h3>You do not have permission to view this directory or page using the credentials that you supplied.</h3>
</fieldset></div>
</div>
</body>
</html>
200:
HTTP/1.1 200 OK
Content-Type: application/vnd.ms-fontobject
Last-Modified: Tue, 13 Aug 2013 10:43:18 GMT
Accept-Ranges: bytes
ETag: "067e7eb1198ce1:0"
Server: Microsoft-IIS/7.5
Persistent-Auth: false
X-Powered-By: ASP.NET
WWW-Authenticate: Negotiate oYGgMIGdoAMKAQChCwYJKoZIgvcSAQICooGIBIGFYIGCBgkqhkiG9xIBAgICAG9zMHGgAwIBBaEDAgEPomUwY6ADAgEXolwEWl1ljYO00B8Uphl5NsfdQu3+5k9yJlSL2JTRqcofSeQ9oylbvSVbHKLWvBrFned5/+Sxodxe6MkY+IB0xEvtp3FVXB4HM3MuanzmqUo7p58L+wDxxG7hdnRgsA==
Date: Wed, 16 Oct 2013 15:36:17 GMT
Content-Length: 29360
�r���q����������������������LP�����������������������#M
�������������������F�o�n�t�A�w�e�s�o�m�e����R�e�g�u�l�a�r���$�V�e�r�s�i�o�n� �3�.�1�.�0� �2�0�1�3���&�F�o�n�t�A�w�e�s�o�m�e� �R�e�g�u�l�a�r�����BSGP�������������������q��q��e�����Y�D
M�F�x���>��ޝ��Ə)[1ɵH���-A)F��ٜ1��.�/
d�U'�&a

Related

codename-one.appspot.com 500 error when attempting to migrate old device id

When I execute
curl -i "https://codename-one.appspot.com/token?m=id&i=d116845c6825ac151489ab33725285e5f48b3e0225285e5f48b3e02"
The result is:
HTTP/1.1 500 Internal Server Error
X-Cloud-Trace-Context: 3f022af7dc49c7650be2fa82421a8511
Date: Tue, 06 Jun 2017 18:25:36 GMT
Content-Type: text/html; charset=UTF-8
Server: Google Frontend
Content-Length: 323
Alt-Svc: quic=":443"; ma=2592000; v="38,37,36,35"
<html><head>
<meta http-equiv="content-type" content="text/html;charset=utf-8">
<title>500 Server Error</title>
</head>
<body text=#000000 bgcolor=#ffffff>
<h1>Error: Server Error</h1>
<h2>The server encountered an error and could not complete your request.<p>Please try again in 30 seconds.</h2>
<h2></h2>
</body></html>
This seems to happen when running the example (with six 9s) from https://www.codenameone.com/blog/new-push-servers.html
How can I tell if an old device id exists or if this is a temporary error with the servers?
That id is incorrect as the old device ids were purely numeric and your number contains both a d and an e character

Font Awesome With HTTPS

So I'm experiencing an issue with Font Awesome in IE8 when using HTTPS in my own site and this is even reproducible on Font Awesome's own site. If I go to Font Awesome over HTTPS in IE8 I get boxes for all of the icons however if I go to Font Awesome over HTTP I get the icons rendered correctly.
What is the problem here? I've heard it could be something to do with the relative font paths in Font Awesome over HTTPS but not sure about that.
Here is a screenshot for those who like such things:
Update
So here is the code that references the fonts and loads the CSS. I'm going to use the code from Font Awesome's site since this seems to be an issue with Font Awesome and not
necessarily something with my site:
HTML that references CSS and an icon:
<link rel="stylesheet" href="../assets/css/site.css">
<link rel="stylesheet" href="../assets/css/pygments.css">
<link rel="stylesheet" href="../assets/font-awesome/css/font-awesome.css">
...
<div class="fa-hover col-md-3 col-sm-4">
<i class="fa fa-adjust"></i> fa-adjust
</div>
Within in font-awesome.css:
#font-face {
font-family: 'FontAwesome';
src: url('../fonts/fontawesome-webfont.eot');
src: url('../fonts/fontawesome-webfont.eot?#iefix') format('embedded-opentype'),
url('../fonts/fontawesome-webfont.woff?v=4.0.3') format('woff'),
url('../fonts/fontawesome-webfont.ttf?v=4.0.3') format('truetype'), url('../fonts/fontawesome-webfont.svg?v=4.0.3#fontawesomeregular') format('svg');
font-weight: normal;
font-style: normal;
}
I've determined the issue and will post the answer in case anyone else experiences the same issue. The problem was with the HTTP cache headers we were sending along with the font file. Apparently this causes IE8 over HTTPS to not load the fonts for some reason (if anyone knows the true reason please comment below). The successful headers should look like this:
HTTP/1.1 200 OK
Content-Type: application/vnd.ms-fontobject
Date: Wed, 26 Mar 2014 23:57:04 GMT
ETag: "08b27bc96115c2d24350f0d09e6a9433f"
Last-Modified: Wed, 26 Mar 2014 12:10:02 GMT
Server: Apache-Coyote/1.1
Content-Length: 38205
Connection: keep-alive
but instead were being sent like this:
HTTP/1.1 200 OK
**Cache-Control: max-age=31556926, must-revalidate
Content-Type: application/vnd.ms-fontobject
Date: Wed, 26 Mar 2014 23:58:06 GMT
ETag: "08b27bc96115c2d24350f0d09e6a9433f"
**Expires: Fri, 27 Mar 2015 05:46:52 GMT
Last-Modified: Wed, 26 Mar 2014 12:12:12 GMT
**Pragma: no-cache
Server: Apache-Coyote/1.1
**Set-Cookie: JSESSIONID=844B0798B373A3B8ED54A694C9DFB5C5; Path=/; Secure; HttpOnly
Content-Length: 38205
Connection: keep-alive
This happens in IE only with https.
Remove any HTTP headers from the fontawesome relevant files that prevent caching, e.g.
Expires -1
Pragma: no-cache
After removing the cache control for these files you should see your icons. After reloading your page all the relevant fontawesome files should show HTTP code 304, i.e. the file comes from the browsers cache.
i think the same,
something to do with the relative font paths in Font Awesome over HTTPS
add NoCacheHeaderFilter in web.xml and provide the exclude file paths.
<filter>
<filter-name>NoCacheHeaderFilter</filter-name>
<filter-class>NoCacheHeaderFilter</filter-class>
<init-param>
<param-name>exclude</param-name>
<param-value>^/(image|css|js|fonts|lib|partials)/.*</param-value>
</init-param>
</filter>
add filter like this.
if (null != exclude) {
HttpServletRequest httpRequest = (HttpServletRequest) request;
HttpServletResponse httpResponse = (HttpServletResponse) response;
String context = httpRequest.getContextPath();
String path = httpRequest.getRequestURI().substring(context.length());
if (!exclude.matcher(path).matches()) {
httpResponse.setHeader("Pragma", "no-cache");
httpResponse.setHeader("Cache-Control", "private, max-age=0, no-store, no-cache");
httpResponse.setDateHeader("Expires", System.currentTimeMillis());
}
}
chain.doFilter(request, response);
The practical answer is,using a proxy, to hide to the browser any cache-control and pragma: "no-cache" header returned to the browser.
I used nginx like this, adding the folowing commands the https proxied location:
proxy_hide_header Cache-Control;
proxy_hide_header Pragma;
See here for details.

Transfer-Encoding: chunked not handled by Chrome

I'm running a web application using Tomcat 7. The app is returning everyone's favorite HTTP header, Transfer-Encoding: chunked. When I navigate to the root url with Chrome (and Firefox, fwiw), Chrome only downloads the first 16384 bytes of the resource. The resource is definitely larger than that size. Why is Chrome only fetching the initial chunk? I see this when accessing the resource with curl:
$ curl -i http://localhost:8080
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=9C7D0EE5D26AD7C99551204CE2896422; Path=/; HttpOnly
Content-Type: text/html;charset=UTF-8
Transfer-Encoding: chunked
Date: Tue, 03 Dec 2013 23:07:09 GMT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
(I know there are several questions on this topic, but they seem to involve disabling Transfer-Encoding: chunked. I want to know why Chrome isn't handling the situation correctly.)

HTML 5 Manifest has different behavior across multiple browsers

I added some settings on my HTML 5 Manifest which resulted perfect behavior on Google Chrome and
Safari on iOS and Safari as a web clip on iOS.
Unfortunately the same code results in abort on loading manifest files in IE and Fire Fox.
Here is the settings we applied:
In server side: IIS 7, Windows Server 2008 R2.
Response: text/cache-manifest , no-cache.
And the text of manifest is :
CACHE MANIFEST
CACHE:
/
/Index.html
/Login.html
/favicon.ico
/Content/Kendo/web/Font/FontAwesome.otf
NETWORK:
*
And here is the result of IE Network profiler for the first file
URL: http://192.168.0.220:1009/
Method:
Result: (Aborted)
Type: text/html
Received: 292 B
Taken: < 1 ms
Initiator: (Pending...)
And here is the response:
Key Value
Response HTTP/1.1 200 OK
Cache-Control no-cache, no-store
Pragma no-cache
Content-Type text/html
Expires -1
Last-Modified Mon, 23 Sep 2013 16:05:06 GMT
Accept-Ranges bytes
ETag "351169ab76b8ce1:0"
Server Microsoft-IIS/7.5
X-Powered-By ASP.NET
Date Mon, 23 Sep 2013 16:32:43 GMT
And this is a error message of html 5 manifest:
Resource doesn’t exist on the server: 'http://192.168.0.220:1009/'.
AppCache Fatal Error
And finally I've these meta tags on Index.html page:
<meta name="apple-mobile-web-app-capable" content="yes" />
<meta name="apple-mobile-web-app-status-bar-style" content="black" />
<meta http-equiv="CACHE-CONTROL" content="NO-CACHE" />
<meta http-equiv="EXPIRES" content="0" />
<meta http-equiv="PRAGMA" content="NO-CACHE" />
Any help highly appreciated.
I've found a reason for the problem.
In Request_End in ASP.NET Global.asax we should apply
HttpContext.Current.Response.Cache.SetNoStore();
only for iOS, and chrome is always working, both for updating application and for offline usage.
Note: no-store is needed in web clip and safari of iOS, because of files which are already loaded before updating manifest, else they won't be updated, even when manifest downloads new version of them.
Hope this helps you too.

Google Chrome Developer tools - CSS file showing as an image resource

I'm running the beta of Google Chrome (12.0.742.60)
My page displays fine, however for some reason, in the Developer Tools 'Resources' tab, it's CSS file is shown under the 'Images' disclosure triangle instead of 'Stylesheets' (where the typekit.com CSS is as expected.) Grateful for any ideas..
CSS tag:
<link rel="stylesheet" type="text/css" href="/styles/lofkch.css" />
CSS response headers (via 'Web Developer' extension):
Date: Sat, 21 May 2011 18:52:30 GMT
Content-Length: 9218
Last-Modified: Sat, 21 May 2011 18:40:50 GMT
Server: Apache
ETag: "5ff9-2402-4a3cd93cab080"
Content-Type: text/css
Accept-Ranges: bytes
200 OK
Live page - REMOVED - see answer for cause.
Aside: There was an excellent Google IO session on the new features in GDT earlier this month.
What happens if you remove the empty background-image?

Resources