Kentico preventing default document from loading

Kentico's URL Rewrite engine is causing the problem but only because you haven't told Kentico to not look at that URL. In Settings > URLs and SEO > URL format, add the /test path in the Excluded URLs textbox. This tells Kentico to not process that relative URL using the Kentico URL Rewrite engine, use IIS instead.

Hello Brenden,

Thanks for the info, however, our currently Kentico 9 installation does not have these exclusions and it works as intended. Also, we have hundreds, if not thousands of directories that should not be managed by Kentico and as we manually convert these older asp.net pages into kentico, we map the paths and remove the files from the web server.

Here's an example of our current live Kentico 9 installation which is handling this situation without using exclusions (the exclusion field is completely blank):

http://www.lamission.edu is running Kentico The following page is on the same webserver but is not mapped in Kentico. The default document works with this path as intended: http://www.lamission.edu/titlev/

however, if I try this same path on the Kentico 11 installation on the staging server http://localhost/titlev/, I get a 404 (see screenshot). If I manually add /titlev to the exclusion list in the Kentico 11 installation then it works as intended however, this is not what's going on in the Kentico 9 installation. Maybe this was a bug in Kentico 9 that it so happens to have benefited our situation or maybe there's a IIS setting or something else. I vaguely recall running into this issue a few years ago and somehow resolved it. I guess I'm after that "somehow" at this point or perhaps another method to allow default documents that are not mapped in Kentico to work as they did traditionally.

Did you add the exclude in the location I metnioned in the v11 instance? I know it's working in v9 but could very well be with the .net upgrades and everything else in v11, that is now working as expected.

Brended,

Yes, when I add the exclusion, it fixes the issues however as I mentioned, we have thousands of non-Kentico related pages and there's no way we can add all these paths to the exclusion list and then manually remove them once we convert them to Kentico so that's out of the question.

I managed to get it working by removing the ExtensionlessUrlHandler-Integrated-4.0 managed handler in IIS by modifying the Kentico web.config:

<system.webServer>
  <handlers>
    <remove name="ExtensionlessUrlHandler-Integrated-4.0"/>
    ...
  </handlers>
</system.webServer>

I don't know if this has any unintended consequences but with some brief testing, it looks like it's now working as it did with V9. I will do more extensive testing to make sure nothing is broken or if you have any knowledge on the consequences of removing this module, I'd appreciate any info as well. Strange thing is that this module is enabled on the V9 instance and it has no effect.

I just wanted to update my own post to post the resolution. In regards to my last post where by removing the ExtensionlessUrlHandler-Integrated-4.0 handler, after further testing, this seems to break Kentico's URL mapping feature so I had to abandon this solution.

I contacted support and even though I didn't get a clear answer back, further testing by simply installing Kentico 9 and observing the default document handling and simply upgrading the version 10 and observing how it has changed, the best guess as to what's going on here is that the logic behind Kentico to handle a URL through the CMS or redirect the request to the file system has changed. Prior to V10, if the path /foobar was not mapped in Kentico and /foobar was NOT in the excluded URL list, a request to http://domain.com/foobar loaded the default IIS document if the physical path existed on the webserver. After V10, the default IIS document no longer loads on such a request, instead a 404 is thrown through the ExtensionlessUrlHandler-Integrated-4.0 handler even though the physical path exists and a default document exists in that path. Also to note that if a request to the default document is made directly such as http://domain.com/foobar/default.aspx, the physical document IS loaded even though the /foobar path is not in the exclusion list in Kentico.

The issue comes when you already have an existing asp.net website that you deploy Kentico onto. Prior to Kentico v10, this was completely transparent to the client as all previous links that lead to default physical documents worked as expected (http://domain.com/foobar or http://domain.com/foobar/default.aspx) as long as those paths were not mapped in the CMS. After upgrading to V10, the former URLs no longer work unless they are explicitly added to the URL exclusion list. This breaks your website if you have URLs anywhere that reference a directory where by you expect IIS to load the default document. Upon looking at the changelog, I could not find any bug fixes or changes that directly reference this change.

The workaround or hack I came up with involves intercepting the request in the Global.asax.cs file in the Application_BeginRequest() method, querying the Kentico tables (CMS_Document and CMS_DocumentAlias) to see if the path is mapped or not, if not, then a check is made to the physical file system to see if a default document exists at the requested path and if so, a Response.Redirect() is made to the default document directly. Caching and other performance related measures are also taken to ensure minimal performance hit. If anyone would like the code to this, I'd be happy to share.