Problem with a URL that ends with %20

Question

I have a big problem. There are devices in live that send the URL "/updates ". It's a typo of the developer for those devices. In the server logs, it looks like "/updates+".

I have a ManageURL rewriting module that handles all requests without extension. But this request causes an HttpException:

System.Web.HttpException:

System.Web.HttpException
   at System.Web.Util.FileUtil.CheckSuspiciousPhysicalPath(String physicalPath)
   at System.Web.HttpContext.ValidatePath()
   at System.Web.HttpApplication.ValidatePathExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

As I see in the logs, the URL rewriting module does not even get this URL, so I cannot fix it there.

Is there a way to handle those URLs with ASP.NET?

Are you using the IIS rewriting module or did you write your own module that does the rewriting? — Andrew Hanson, Jul 14 '09 at 17:16

score 22 · Accepted Answer · edited May 23 '17 at 12:34

22

Ok, this is an old thread, but I like to add a workable solution that works for all ASP.NET versions. Have a look at this answer in a related thread. It basically comes down to registering to the event PreSendRequestHeaders in global.asax.cs.

Alternatively, when on ASP.NET 4.0 or higher, use <httpRuntime relaxedUrlToFileSystemMapping="true" /> in web.config.

edited May 23 '17 at 12:34

Community

1
1

answered Mar 11 '11 at 12:48

Abel

56,041
24
146
247

score 1 · Answer 2 · edited May 23 '17 at 10:30

1

According to some, this is in System.Web.dll:

internal static void CheckSuspiciousPhysicalPath(string physicalPath)
{
  if (((physicalPath != null) && (physicalPath.Length > 0))
    && (Path.GetFullPath(physicalPath) != physicalPath))
  {
    throw new HttpException(0x194, "");
  }
}

I guess you cannot change that, but can't one disable it in the IIS settings? Of course, that would also disable all other checks... :-(

Or write some ISAPI filter that runs before the above code? Writing your own module is said to be easy, according to Handle URI hacking gracefully in ASP.NET.

Or, create your own error page. In this page (like suggested in the URI hacking link above) search for specific text in exception.TargetSite.Name, such as CheckSuspiciousPhysicalPath and if found (or simply always) look at current.Request.RawUrl or something like that, clear the error and redirect to a repaired URL?

edited May 23 '17 at 10:30

Community

1
1

answered Jul 14 '09 at 17:46

Arjan

22,808
11
61
71

Thanks. Sorry for not ansering so long. As temporary fix we create a 404 page. And find a way to change it on devices. Anyway this error pushed me to find a ISAPI module that can handle those issues. – AlfeG Jul 28 '09 at 13:51
Welcome back ;-) Actually, I guess Cheeso's answer about using an ISAPI rewriting filter might be an easy workaround. This would then hopefully run *before* the above code is executed -- but I think Cheeso is the author of that filter, and I trust the author knows best. The single upvote for Cheeso's answer is mine, so: did you read that answer? – Arjan Jul 28 '09 at 14:45
@AlfeG: Just to answer _"I guess you cannot change that"_ >> you actually can, by registering to `PreSendRequestHeaders`. See my newly added answer, or see http://stackoverflow.com/questions/429963/the-resource-cannot-be-found-error-when-there-is-a-dot-at-the-end-of-the-url/5272936#5272936 – Abel Mar 11 '11 at 12:49
(Nice, @Abel. See also [How do comment @replies work?](http://meta.stackoverflow.com/questions/43019/how-do-comment-replies-work) AlfeG was not notified of your comment, but will have been notified of your new answer, so that's no problem now.) – Arjan Mar 11 '11 at 12:58
(Ah, I see. So in this case, only using @AlfeG will warn him, specifying multiple users won't. Tx for explaining) – Abel Mar 11 '11 at 13:28

score 1 · Answer 3 · answered Jul 17 '09 at 10:54

1

you could run a URL-rewriting ISAPI, like IIRF.

answered Jul 17 '09 at 10:54

Cheeso

189,189
101
473
713

IIRF was not an ideal solution for our application. I'm waiting for release of 2.0 version. – AlfeG Jul 29 '09 at 13:25
IIRF 2.0 is out and available, though not final. But there's nothing in the rewrite engine for IIRF v2.0 that you cannot get in IIRF v1.2.16. – Cheeso Jul 29 '09 at 13:38
Like I wrote in the comments of my own answer: I assume that IIRF runs prior to any built-in security in IIS? So, one could completely rewrite any URL (or: just strip an erroneous trailing space) before handling control to IIS, so before `CheckSuspiciousPhysicalPath` is invoked. Right? Seems like a good solution to me, but still the single upvote is mine. Am I missing the point here? – Arjan Aug 03 '09 at 12:16
@Arjan, no I don't think you are missing the point. You are correct that the ISAPI filter will run prior to System.Web.dll checking for a suspiscious path. My comment about IIRF v2.0 was directed to AlfeG, who said he was waiting for v2.0. I wanted to say, for rewrite purposes, there's no point in waiting. IIRF v1.2 or v2.0 will both accomplish the goal. – Cheeso Aug 03 '09 at 12:47
Exactly what I thought. (I did understand you were replying to AlfeG, but I just fail to understand why AlfeG thinks IIRF is *not* an easy solution, even if only to remove one space... Not such a big problem after all?) – Arjan Aug 03 '09 at 13:59

score 0 · Answer 4 · answered Jul 14 '09 at 17:15

0

If you have access to code why not just check for '+' at the end and remove it?

answered Jul 14 '09 at 17:15

Bostone

36,858
39
167
227

Problem with a URL that ends with %20

4 Answers4

Linked