For those unfamiliar, the ValidateRequest property of a page tells ASP.NET whether to check the form fields, querystring & cookies for malicious input -- this that could be used for cross-site scripting attacks. Obviously, one should not disable this unless they know what they're doing.
I know what I'm doing. I know the consequences, and the caveats, etc etc. This isn't so much about whether I should be disabling the feature, but more about how precompilation of your ASP.NET site may affect this.
For an ASP.NET 2.0 web applicatation of ours, we have a need to deploy to two locations: One with validateRequest=false for all pages, and one with validateRequest=true for all pages.
So, like a good little ASP.NET'er, I place the following in my web.config file...
I figured then I would change the value to false when we deployed to the server that we didn't want to have validation.
This worked fine in development, and would have worked fine, except that thanks to some handy MSBuild scripts (newly rewritten), we were pre-compiling the site before the deployment.
Normally, changing the web.config would cause the entire website to be re-compiled, and thus a change to the <pages /> tag would get picked up. With a precompiled site however, certain parts of the web.config are COMPILED INTO THE GENERATED ASSEMBLIES. Thus, changing the <pages /> section of the web.config file after the site has been deployed HAS NO EFFECT.
It makes sense, but the documentation is thin. There are a number of workarounds, including marking your precomiled site to be "updatable". K. Scott Allen outlines these nicely. In the end, we've decided to precompile each site individually, using the correct web.config file, and with our MSBuild scripts, this is a no-brainer.