HTTP 403.14 and 404.3: IIS will not serve the files that are clearly there

Fix it now

The content is on disk and IIS has nothing configured that is allowed to send it. Microsoft publishes 403.14 as directory listing denied, 404.3 as a MIME type restriction and 404.4 as no handler configured. None of the three means the file is missing.

%windir%\system32\inetsrv\appcmd list config "Default Web Site/" /section:handlers
%windir%\system32\inetsrv\appcmd list config "Default Web Site/" /section:staticContent
%windir%\system32\inetsrv\appcmd list config "Default Web Site/" /section:defaultDocument

1. For 404.3, add the missing MIME mapping: IIS Manager, select the site, open MIME Types, choose Add, and enter the extension with its leading dot and the correct content type.
2. For 403.14, add the default document that matches a file which actually exists in the folder, rather than switching directory browsing on.
3. For 404.4, open Handler Mappings on the site and confirm a mapping exists for the path and verb being requested.
4. If nothing static is served at all, the static content role service is probably not installed. Read the exact feature name off Get-WindowsFeature Web-* and install that one, rather than copying a name out of an article.
5. For an application root returning 403.14, install the role service or module for the framework the application uses, then run iisreset.

Directory browsing makes a 403.14 disappear by publishing a full listing of the folder to anyone who can reach the URL. Enable it only on a folder you have deliberately decided to make public.

If the content is served, you are done. If it is not, the next section explains how a request finds something willing to handle it, and where in that chain yours is falling through.

Why it happens

IIS matches every request against its handler mappings before anything reads the disk. A mapping ties a path or extension and a verb to a module. If a mapping matches, that module owns the request. If none matches, there is nothing to run, and 404.4 is published as exactly that: no handler configured. It is a configuration answer, not a file system one.

Static files are served by a module that will only send file types it has a MIME mapping for. That is deliberate. It stops the server handing out configuration files, databases and source that happen to sit in the web root. When you request an extension with no mapping, Microsoft publishes the result as a MIME type restriction, 404.3, and the fix is to add the one mapping rather than to loosen anything.

403.14, published as directory listing denied, comes last in that chain. The request resolved to a directory, the default document module worked through its list and matched none of them, and the directory listing module was asked to render the folder instead. Directory browsing is off by default, so it refuses. The common real cause is not a missing index file at all: it is an application whose handler was never registered, so requests that should have gone to the application fall through to plain directory handling.

500.37 belongs in the same conversation for a different reason. It is the ASP.NET Core Module reporting that the application did not start inside its startup time limit, which defaults to 120 seconds. A slow-starting application on a cold pool can look like a serving problem to somebody watching a browser, and it is not one.

Full reference

Matching what you see to what is missing

Reading the three sections that decide this

Run these from %windir%\system32\inetsrv, or call appcmd by its full path. The effective configuration is the merge of every level above the one you ask about, so a mapping you cannot find in the site’s own web.config may be arriving from applicationHost.config.

MIME types, and where to stop

• Add the specific type for content you intend to publish. That is what the mapping is for.
• Do not configure the server to serve any unlisted extension. The restriction exists to stop the web root handing out whatever ends up in it.
• Add at site level unless every site on the box needs it. A long server-wide list is checked on every request and makes behaviour harder to reason about.
• Use the correct content type, not a generic one you know will work. Fonts, scripts and media are handled differently by browsers depending on the type they are given.

Default documents, and the trap in them

A default document list is checked in order on every folder request, and the first entry that matches a file present in the folder wins. That has two consequences worth knowing. A long list at server level costs something on every request. And adding a default document to an application root, to silence a 403.14, produces a site that appears to work while the framework’s handler is still not registered, so anything with a route rather than a file behind it keeps failing.

Directory browsing publishes a full listing of the folder to anyone who can reach the URL, including files you never intended to expose. It makes a 403.14 disappear and it is almost never the right fix. Turn it on only where you have deliberately decided the folder should be public.

Two event IDs you will see quoted for this, and what to do with them

Event ID 2276 and Event ID 2280 turn up in the System log on servers with module problems, and they are widely quoted as meaning a module DLL failed to load. Microsoft does not publish a meaning for either of them, so this article will not tell you one. Read the entries on the machine: they are written by the IIS worker process source and they carry the detail themselves. Then diagnose from the 500.19 HRESULTs above, which are published and which cover the same fault properly.

When the mapping is right and it still will not serve

• Confirm the request is reaching the site you think it is. Host headers and bindings send requests to a different site more often than anyone expects.
• Check the IIS log for the request and read sc-status and sc-substatus together, so you are diagnosing the sub-status you actually have.
• Check request filtering. A request rejected by filtering is not a handler problem and produces a different sub-status.
• Confirm the file is where the physical path says it is, and that the pool identity can read it. A permission failure on the folder produces a 401.3, not a 404.

Every code this article covers

Confirm the fix worked

1. Request the previously failing URL and confirm the expected content is returned.
2. Request a file of the same type from a different folder, to confirm the mapping applies where you intended.
3. Run appcmd list config "<site>/" /section:handlers and confirm the mapping you added is in the merged result.
4. Check the IIS log for the request and confirm sc-status 200 with sc-substatus 0.
5. Confirm directory browsing is still disabled on every folder where you did not deliberately enable it.

Questions people ask about this