Iis – Two different sites, same IP, same top-level domain, on IIS 7.5 — one works and the other displays HTTP 404 error

ASP.NET does not support having multiple built-in authentication modules at once. This is prominent in the documentation, <authentication mode="[Windows|Forms|Passport|None]" ...>

Solutions:

• Build a custom IHttpModule which handles authentication.
• Separate your application into two web applications in your IIS, which point towards two different directories with different configuration files. This is the easiest solution.
• Separate your application into two web applications in your IIS, but point both of them to the same directory. You will need to remove the authentication- and impersonation settings from the web.config residing in the directory, and move these into the system-wide web.config (%SystemRoot%\Microsoft.NET\Framework64\v4.0.30319\Config\web.config or similar). These settings must be wrapped by location-tags using the name of the IIS-site.

Example:

<location path="My Awesome Site - Forms">
    <system.web>
        <authentication mode="Forms" />
    </system.web>
</location>

<location path="My Awesome Site - Windows">
    <system.web>
        <authentication mode="Windows" />
        <identity impersonate="true"/>
    </system.web>
</location>

This is by design. A URL Reservation is not the same as a URL Registration, which happens dynamically when an application registers with HTTP.SYS to being listening. In the case of a URL Reservation, HTTP.SYS does not know whether the URL in a given Reservation is simply unavailable temporarily or does not exist at all. All it can know in this case is that there is a valid host name match (because of your strong/weak wildcard), but the URL path does not match for any currently registered listeners.

If you want a 400 or 503 response, then either do not use any URL Reservation, or use explicit URL Reservations that do not include wildcards. In short, if you configure HTTP.SYS such that it can match the prefix of the URL to any Reservation (including dynamic ones created via Registration), then it will either deliver the request to listening application (if the rest matches), or return a 404 if it can't find an active registered listener.

Another solution that may be simpler is to use the IIS service itself to manage sending a 503. To do this don't stop the site, but instead stop the Application Pool(s) associated with it. This will cause a fully qualified match to occur in HTTP.SYS (even with wlidcard URL Reservations), but will result in a 503 because there is no AppPool to deliver the request to.