4

For some reason my IIS won't return any font files. They all return as 404s. I have verified the URLs are correct and the MIME types are correct. The font files are currently inside of a .NET 4.5 project using MVC4. When I move the files outside of the project, into the server's root directory, it serves the files up fine. I have verified there aren't any overrides happening in the project's web.config to how the file extensions are handled.

So far this is happening for .TTF, .EOT, .SVG, and .WOFF files. Other static files, in the same directory, are returned fine. Is there some setting in IIS8.5 that prevents the font files from being returned?

I have attached a log file which was generated by the failed request tracking.

https://dl.dropboxusercontent.com/u/39382497/fr000001.xml

Chris Peterson
  • 233
  • 3
  • 8
  • I just installed IIS8.5 to check, and the MIME types for those files are certainly registered by default. Have you checked the file permissions on the font files? Have you tried explicitly adding the relevant MIME types for your web site? – Andrew Morton May 16 '14 at 18:25
  • I've moved the files into a different directory at the same level, where static files are being returned, no help. I tried adding several different MIME type definitions as well to no avail. – Chris Peterson May 17 '14 at 02:04
  • If you *move* files they retain their file permissions. If you *copy* files they inherit the inheritable permissions of the location to copy them to. Of course, it is easier to just check the permissions on the file itself and compare them to a file which is served correctly. – Andrew Morton May 17 '14 at 20:20
  • The permissions are exactly the same. If it was a permissions issue, it wouldn't be throwing a 404, would it? – Chris Peterson May 18 '14 at 00:37
  • How annoying. Yes, it would give a 404 status if the permissions were wrong. An easy way to confirm that IIS is trying to retrieve the correct file is to use [Process Monitor](http://technet.microsoft.com/en-us/sysinternals/bb896645) and filter on the filename, e.g. "abrilfatface-regular-webfont.svg". – Andrew Morton May 18 '14 at 08:45
  • So I downloaded the process monitor and ran the site with the filter applied. There were 12 entries. All but 2 were were successful. The first entry, "QueryOpen" had a result called "Fast IO Disallowed". The third to last entry, "QueryAllInformationFile" had a result of "Buffer Overflow". Are one of these causing the problem? – Chris Peterson May 18 '14 at 13:09
  • ...and did any of the entries have something along the lines of "Access denied"? You wrote that it serves other static files correctly from the same directory: did you mean the actual "fonts" directory or its parent? If the latter, can you try putting a plain .txt file in that "fonts" directory you're using and see if that is served correctly by putting its URL directly in a browser address bar? If it doesn't serve the .txt file, I suggest deleting that directory and re-creating it. – Andrew Morton May 18 '14 at 13:30
  • Also, you might want to check the Request Filtering settings just in case something has got in there by accident which would prevent the font files from being served. – Andrew Morton May 18 '14 at 13:33
  • I'm not 100% sure what I did but somehow the files are being served again. I was working on some other problems and must have fixed it without realizing. One thing I did was switch the project to a different application pool. As far as I can tell, though, the old app pool and new one are the same and there aren't special privileges on the files or folders within the project. I'm stumped but I'm glad it is working. – Chris Peterson May 18 '14 at 21:43

3 Answers3

6

This issue seems to have fixed itself through the course of working on the project. Andrew Morton provided some excellent trouble shooting steps for anyone else having similar issues. I'll provide quick list:

  • Verify the correct MIME type is being used by the server. Using IIS Manager > Server > Project > MIME Types. Here are the list of MIME types that are working for me:

    • .eot = application/vnd.ms-fontobject
    • .svg = image/svg+xml
    • .ttf = application/octet-stream
    • .woff = application/x-font-woff

  • If That doesn't work verify the web server has permissions on the project folder and the folder storing the files. Following a tutorial will help a lot.

  • Futher debugging using a tool such as ProcessMonitor will help narrow down more stubborn server issues.

Hope this helps someone.

Chris Peterson
  • 233
  • 3
  • 8
0

try this:

  1. create an html file in [your editor of choice] that writes something descriptive out to a browser such that you know it has been resolved:

    delerium tremens, no big deal

  2. test it to ensure it's valid html
  3. place it in the directory from which your fonts are sourced - evidenced by the 404 errors in [your browser of choice]'s development tools (should be a relative path)
  4. navigate to it - does it resolve?

if yes, it's a configuration issue with the mime types in your application server

if no, your fonts are not resolved because the expected path is incorrect - look at the 404 error for the .html file and it should reveal from whence the application server is looking for your fonts by displaying a unc path relative to the web root

TGD
  • 1
0

I diagnosed my resolution to this by examining the Status Codes of in the ISS Error Log.

sc-status sc-substatus sc-win32-status

500 0 1346

The win32 status indicates that

ERROR_BAD_IMPERSONATION_LEVEL

1346 (0x542)

Either a required impersonation level was not provided, or the provided impersonation level is invalid.

https://docs.microsoft.com/en-gb/windows/win32/debug/system-error-codes--1300-1699-

It turns out that there is an MS article on this fault.

https://blogs.msdn.microsoft.com/asgoyal/2012/08/25/one-thing-you-must-do-when-getting-http-500-0-1346-error/

Check if the Application Pool Identity for the respective application is a part of ‘Impersonate a client after authentication’ policy. It is a requirement that the application pool identity must be a part of this policy, directly or by inherited membership.

To check this policy – go to start –> run –> secpol.msc –> Local Policies –> User Rights Assignment

For me the issue was that the 'IIS_IUSRS' group was missing from this policy.

Nattrass
  • 127
  • 1
  • 8