We are migrating from ASP.Net to ASP.Net Core.
We need to configure different authentications for different paths
<location path="controllerpath/method">
<system.webServer>
<security>
<authentication>
<anonymousAuthentication enabled="true" />
</authentication>
</security>
</system.webServer>
</location>
But as soon as we add the <location path="xyz">
entry the specified path is no longer reachable and the caller get's a 404 error. Even just putting
<location path="xyz/abc">
</location>
Is enough to trigger the 404 response. If I remove this entry is can be accessed again. The 404 comes from IIS directly, because even if the app fails to start (and all other calls result in a 503 for example), the path specified via location path still results in a 404.
Here is the full web.config:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<location inheritInChildApplications="false">
<system.webServer>
<handlers>
<remove name="aspNetCore"/>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified"/>
</handlers>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="52428800"/>
</requestFiltering>
<authorization>
<add accessType="Allow" users="*" verbs="OPTIONS"/>
</authorization>
</security>
<aspNetCore processPath="dotnet" arguments=".\assembly.dll" hostingModel="inprocess">
<handlerSettings>
<handlerSetting name="debugLevel" value="file" />
<handlerSetting name="debugFile" value="c:\temp\ancm.log" />
</handlerSettings>
<environmentVariables>
<environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
</environmentVariables>
</aspNetCore>
<httpProtocol allowKeepAlive="false">
<customHeaders>
<remove name="X-Powered-By"/>
</customHeaders>
</httpProtocol>
<directoryBrowse enabled="true"/>
<httpCompression>
<dynamicTypes>
<remove mimeType="*/*"/>
<add mimeType="*/*" enabled="true"/>
</dynamicTypes>
</httpCompression>
</system.webServer>
</location>
<location path="xyz/abc" allowOverride="true">
</location>
</configuration>
<!--ProjectGuid: 29529648-A3F4-44CB-827B-B6B81B00A09C-->
I found the solution:
the attribute inheritInChildApplications="false"
made it that the handler was not registered for the other paths. After removing the attribute (or changing the value to true) everything works as expected. I guess IIS then tried to locate the path as a resource.