A customer reported that an MVC application I develop fails when trying to access a page called “Reports”, which unsurprisingly resides under the URL /Reports below application root, implemented by the class ReportsController.
On a different installation, the error does not occur, but that installation is not installed in web site root – rather, the installation which allows /Reports to be executed is a web application inside a web site.
A web search led me to a comment on Stack Overflow, where the same problem had been reported 3 years ago:
Do you by any chance have SSRS installed/hosted on your QA server?
And as it happens, the machine in question had SSRS installed 😉
Time for some background information: When an HTTP request hits a Windows machine, IIS is not the first program to process it. Rather, the HTTP request is first handled by HTTP Server in http.sys. Applications register with the HTTP Server API if they process HTTP requests outside of IIS.
And so does SSRS!
http.sys stores a table mapping URL paths and their registered applications. Entering on the command line
netsh http show urlacl
results in a list of URLs registered with http.sys. The /Reports URL shows up both for ports 80 and 443:
Reservierte URL : http://+:80/Reports/ Benutzer: NT SERVICE\ReportServer Abhören: Yes Delegieren: No Reservierte URL : https://SomeServer:443/Reports/ Benutzer: NT SERVICE\ReportServer Abhören: Yes Delegieren: No
See here for documentation of the netsh http command.
So there we have it: the web root directory /Reports is mapped to SSRS, for all IP addresses (and host names) on port 80 (http), and for a specific host name on port 443 (https).
The solution is now to run Reporting Services Configuration Manager and connect to the Reporting Services
Click Advanced, and find the IP Address filter set to “all assigned”
Click Edit and restrict the filter to either IP Address or Host Header Name