Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I use htaccess to handle illegal characters in a request path. This works as expected and routes visitors to the correct error page in WS2K8 R2, but when I migrate to SP1, it instead throws the "potentially dangerous characters in request.path" error before htaccess can handle it. In both environments I am on IIS 7.5.

To solve this, I added the requestPathInvalidCharacters httpRuntime attribute in my web.config to allow all dangerous characters as follows:

<httpRuntime requestValidationMode="2.0" requestPathInvalidCharacters="" />

This prevents returning the potentially dangerous Request.Path error to the browser and allows htaccess to handle the request; however, CheckInvalidPathChars still sends an "Illegal characters in path" exception to the application log and enterprise library still emails the exception.

My questions are threefold:

  1. Why is the httpruntime setting trumping my htaccess rule in SP1 when it does not do this on WS2K8 R2?

  2. Why isn't CheckInvalidPathChars using my requestPathInvalidCharacters setting?

  3. How can I prevent CheckInvalidPathChars from throwing this exception?

Thanks!

share|improve this question

1 Answer 1

up vote 2 down vote accepted

Well, I figured out the answers problem...

  1. It was not that httpruntime was trumping htaccess in SP1, it was that a custom MVC handler that we're using for non ASP.NET MVC files was running after we already redirected the request to the error page. Our custom handler parses the request and its file extension. We were using Path.GetExtension to get the extension, but this method was choking on the invalid characters in the original request.

Prior to SP1, the custom mvc handler was not called after redirecting. I'm not sure why this happens but didn't pursue it b/c we used a workaround--see #3 below.

  1. ASP.NET MVC was using my setting, but the the subsequent Path.GetExtension call was not.

  2. We ended up writing our own GetExtension method, which was exactly like the MS method only without the check for invalid characters. It's not pretty, but it gets the job done...

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.