Trailing dots in url result in empty 404 page on IIS

Question

I have an ASP.NET site on IIS8, but IIS7.5 behaves exactly the same. When I enter a URL like:

mysite.com/foo/bar..

I get the following error with a '500 Internal Server Error' status code:

even though I have custom error pages set up for 500 and 404 and I don't see anything wrong with my custom error page.

In my web.config system.web node I have the following:

<customErrors mode="On">
  <error statusCode="404" redirect="/404.aspx" />
</customErrors>

If I remove that section, I get a 404.0 response back but the page itself is blank.

In web.config system.webServer I have:

<httpErrors errorMode="DetailedLocalOnly">
  <remove statusCode="404" subStatusCode="-1" />
  <error statusCode="404" prefixLanguageFilePath="" path="404.html" responseMode="File" />
</httpErrors>

But whether that is there or not, I get the same blank 404.0 page rather than my expected custom error page, or at least an internal IIS message.

So first of all why is the asp.net handler picking up a request for '..' (also works with one or more trailing dots)

If I remove the following handler from applicacationHost.config:

<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" responseBufferLimit="0" />

I get my expected custom 404 page, but of course removing that handler breaks routing in asp.net among other things.

Looking at the failure trace I see:

Windows Authentication is disabled for the site, so why is that module even in the request pipeline?

For now my fix is to use the URL Rewrite module with the following rule:

<rewrite>
    <rules>
        <rule name="Trailing Dots" stopProcessing="true">
            <match url="\.+$" />
            <action type="Rewrite" url="/404.html" appendQueryString="false" />
        </rule>
    </rules>
</rewrite> 

This works okay, but I wonder why IIS/ASP.NET behaves this way?

Solution 1

Adding this attribute in the httpRuntime section may help you:

<configuration>
  <system.web>
    <httpRuntime ... relaxedUrlToFileSystemMapping="true" .../>
  </system.web>
</configuration>

Gets or sets a value that indicates whether the URL in an HTTP request is required to be a valid Windows file path.

More information about relaxedUrlToFileSystemMapping

Solution 2

There is a KB about this: http://support.microsoft.com/kb/2520479

The upshot of it is that there is an order-of-operations issue where the .NET handlers for various functions get mixed up and misdirect things. Some of the .NET handlers re-write the URL to an extension-less form and they can freak out other things.

The short workaround fix is to move all the "ExtensionlessUrlHandler" handlers to the very end of the list, after any custom ones you have added that might touch the PathInfo data.

It may not be your exact error but it is well worth trying. And worth remembering that the handler order is configured by the ADD order in ApplicationHost.Config and related config files!

Solution 3

I can't give you an answer about why the dotnet framework exhibits this annoying behaviour. It's almost as though it treats the 404 as a handled 404 and skips the default IIS 404 page. Perhaps it sets:

Response.IisTrySkipIisCustomErrors

Microsoft docs

Anyway when I implemented your rule, I tweaked your regular expression to support a trailing . followed by an optional /.

e.g.

https://localhost/investing./

I have updated it to support an optional slash.

<rule name="Trailing Dots" stopProcessing="true">
    <match url="\.+/?$" />
    <action type="Rewrite" url="/404.html" appendQueryString="false" />
  </rule>

I would have added this as a comment, but don't have the rank to do this.

Comments

[Peter Hahndorf]

Thanks Mark, I didn't know about that article, however because I think I submitted the bug-report which lead to that article I already have my ExtensionlessUrlHandlers at the bottom of the list.

[Mark]

Well, then both sorry and congrats. :-/ To go further with this, you might have to post a bit more about what you are doing in the 404.aspx page. Or maybe it isn't your site config that is the issue but the config that controls the 404 stuff. If your 404 page gets .NET involved in handling the PathInfo maybe a second round of modules load and freak-out on the URL then. You got a tricky one!

[Peter Hahndorf]

I removed my 404.aspx from the customErrors, that caused the 500 error I mentioned first. I'm okay with not having it and just to use a static 404.html set in httpErrors. So now I have a 404 which is much better than the 500, but I still get the empty page and not my custom static 404 page. It would be good to know if something I did to my server or site cases this empty page or whether it is a general problem with asp.net on IIS and trailing dots in the URL.