IIS7: URL Rewriting with period
Asked Answered
N

4

6

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 the 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.)

Number answered 21/2, 2011 at 19:46 Comment(2)
Possible duplicate: #430463 “The resource cannot be found.” error when there is a “dot” at the end of the urlParamaribo
Ultimately, he was experiencing the same root problem, but he described his symptoms with different keywords, so I never saw the question. He's also using MVC, which I'm not, and didn't specify his IIS version. Hopefully having both questions out there will help people find the answer to their same problem in the future.Number
D
8

Try changing this setting in your web.config:

<httpRuntime relaxedUrlToFileSystemMapping="true" />

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

Duro answered 27/2, 2011 at 18:16 Comment(3)
Sorry... I should have been more clear. I'm running .Net 2.0, and relaxedUrlToFileSystemMapping is only available starting with 4.0. Do you know of anything for 2.0?Number
I dont think this is possible on .NET 2. If you really need this feature, have you considered migrating to .NET 4?Duro
Yeah, I've come to that same conclusion after reading more about the relaxedUrlToFileSystemMapping attribute. I had to adjust my IIS configuration and some other items in the web.config, but I was able to migrate to 4.0. Thanks.Number
P
0

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

Paramaribo answered 6/3, 2011 at 17:29 Comment(0)
O
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+)

Overburdensome answered 27/3, 2014 at 13:3 Comment(0)
E
0

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

Ellaelladine answered 3/2, 2016 at 10:32 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.