>>Hmm. AFAICS you're right. Even with the replacement validator in effect the default validator still fires first. All the documentation I can find indicates that the custom version should *replace* the default - and there are even a few posts around indicating that this works as a solution. But regardless of the settings for requestValidationMode and any Page validateRequest settings the default fires first. The only way I found to prevent it was to modify the requestPathInvalidCharacters string (and handle any modified check for the removed characters to the custom validation)
>>
>>Bottom line : I couldn't find any way to completely disable the default request validator.
>>I also read that, contrary to what I thought, it is only possible to have *one* custom validator in effect per site - different ones at different levels won't work.....
>>
>>NOTE: all my testing was done using the dev server. Didn't deploy anything to a full IIS site.
>
>Thanks, this is very detailed.
>
>The only think I could see would be to change the requestPathInvalidCharacters in the httpruntime tag in the Web.Config to bypass the default. In it, I could keep all the invalid characters but the & character. Then, I can have the framework to validate on that on the path. Is this pretty much the only way you can see as well?
Yes
>But, that implies that the request would go further into the application dll. Thus, I am not sure if this & character could cause any damage before it reaches the point where I can verify on it. Because, if this is identified as an invalid character, there is probably a security reason for it.
I can't find any info on what might happen in the pipeline between the occurrence of the default validation and the custom validation. I'd guess 'not a lot' but that's not much help :-}
In fact, I'm still mystified as to why we are both seeing this behaviour when everything a read leads me to expect the opposite order of events........
I see Rick Strahl blogged about it (but doesn't mention the role of custom validators):
http://www.west-wind.com/weblog/posts/2010/Aug/19/RequestValidation-Changes-in-ASPNET-40
