IIS7: URL Rewriting with period

I'm using SEO-friendly URLs, and I can process most of them with ASP.NET, by mapping aspnet_isapi.dll to all URLs. (I set up an Handler Mapping in IIS that uses th开发者_JS百科e dll for all paths. (path = *))

However, that doesn't seem to work when the last character of a "subfolder" is a period. E.g., I have a URL of /brakes/A.B.S./, and that won't trigger the mapping. So I end up with 404s for such URLs. Does anybody know how I should setup the mapping to trigger this? (I've tried *. and that doesn't work either.)

---

Try changing this setting in your web.config:

<httpRuntime relaxedUrlToFileSystemMapping="true" />

http://haacked.com/archive/2010/04/29/allowing-reserved-filenames-in-URLs.aspx

---

As Matthew already pointed out, this is resolvable in .NET 4.0, but not in .NET 2.0. The problem lies in the underlying system: Microsoft forbids names to end with a dot (or a space, for that matter), because Windows Explorer cannot handle them (the underlying NTFS system can handle them, however).

What's the cause

Internally, and this is true for .NET 2.0 and .NET 4.0, a web request is passed, at some point, to the method IsSuspiciousPhysicalPath. Among other things, this method calls a standard API to create an "official" path based on the path given. It doesn't create this path. Then it compares this correct path with the given path. If they are different (i.e., if the given path does not exist in the corrected path) it is considered suspicious.

You can try this yourself: use File.CreateFile to create the file "test.txt....". This will succeed, but the resulting file is "test.txt". In the scenario above, the given file "text.txt...." does not fit the created file, hence it is suspicious and never even reaches the web request handler.

Even a 404-handler in the base IIS settings won't work here!

A far-fetched workaround

A workaround which I've used for years in many setups (for reasons not related to this issue): install Apache in front of IIS and configure it for proxying. That's relatively easy to setup (lost of examples on the internet) and this can act as a buffer for handling these kind of "illegal requests", rewriting them to something IIS can handle.

But it is probably easier to simply move from .NET 2.0 to .NET 4.0

---

I'm using Web API attribute routing

The selected answer did not work for me, it is only a partial solution.

to make sure the Web API gets the first crack at it, not only will you need to have

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

you also need to have

<system.webServer>
  <modules runAllManagedModulesForAllRequests="true"></modules>
</system.webServer>

I found the answer here at this blog:

ALLOW A DOT IN ASP.NET MVC APPLICATION (SPECIFICALLY IIS 7+)

---

In my case, I couldn't do it using the URL Rewrite while there was another reason which is the URL Scan.

I opened windows\system32\inetsrv\urlscan\urlscan.ini in a text editor and enabled AllowDotInPath by changing its value to 1