What does requestValidationMode="2.0" actually do?

Question

I'm trying to solve a "A potentially dangerous Request.Form value was detected from the client" problem, and SO answers and Scott Hanselman recommend setting

<httpRuntime requestValidationMode="2.0" />

in Web.config (along with adding an attribute to problematic Methods).
I realize this changes the validation mode to ASP.NET 2.0's, but what does that mean?
And also, does this change has any side effects I should be aware of?

Thanks.

Answer 1

Check out the description at MSDN's HttpRuntimeSection.RequestValidationMode Property.

2.0. Request validation is enabled only for pages, not for all HTTP requests. In addition, the request validation settings of the pages element (if any) in the configuration file or of the @ Page directive in an individual page are used to determine which page requests to validate.

Answer 2

Take a look at ASP.NET Request Validation>

The request validation feature in ASP.NET provides a certain level of default protection against cross-site scripting (XSS) attacks. In previous versions of ASP.NET, request validation was enabled by default. However, it applied only to ASP.NET pages (.aspx files and their class files) and only when those pages were executing.

In ASP.NET 4, by default, request validation is enabled for all requests, because it is enabled before the BeginRequest phase of an HTTP request. As a result, request validation applies to requests for all ASP.NET resources, not just .aspx page requests. This includes requests such as Web service calls and custom HTTP handlers. Request validation is also active when custom HTTP modules are reading the contents of an HTTP request.

As a result, request validation errors might now occur for requests that previously did not trigger errors. To revert to the behavior of the ASP.NET 2.0 request validation feature, add the following setting in the Web.config file:

<httpRuntime requestValidationMode="2.0" />

However, we recommend that you analyze any request validation errors to determine whether existing handlers, modules, or other custom code accesses potentially unsafe HTTP inputs that could be XSS attack vectors.