>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?

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.