One of the new features in ASP.NET 1.1 was Request Validation, an addition that, by default, disallowed users from submitting form fields that contained potential markup. In the classes I teach I find that most developers are unaware of Request Validation's existence, and don't realize that it's there, checking for HTML markup, until they build their first application where they want to let the user submit HTML markup. And then they get the forboding:
Turning off Request Validation is pretty easy. As the Request Validation FAQ explains, you can turn it off on a page-by-page basis, via the @Page directive:
<%@Page ... ValidateRequest=“False“ %>
Or you can set it for the entire Web application through Web.config, or for your entire Web server through machine.config. Today, though, I found an interesting question on the microsoft.public.dotnet.framework.aspnet.webcontrols newsgroup from Umut Tezduyar, who asks:
I want to disable RequestValidation that consumers of my custom control. Is
there a way for this? ... By using the control that i am developing, my users can write html from the web site. But framework 1.1 is disables it by default. ... I want to disable it or allow only from some of my controls can post html text.
The question boils down to, Is there some property a custom, compiled control could set that would disable Request Validation for the page is exists on (or, perhaps, turn it on)? After a bit of poking around with Reflector, it appears that the answer is, No. In fact, to my knowledge you can't programmatically muck with any of the page-level directive values through a page's source code portion.
As I discussed in Understanding ASP.NET View State (see “The ASP.NET Page Lifecycle” section), when an ASP.NET page is visited for the very first time, or for the first time after the HTML portion has been modified, the ASP.NET engine creates an autogenerated class whose primary responsibility is to construct the control hierarchy programmatically, based on the page's HTML markup and Web controls. During this compilation, the page's directives are inspected, and their values affect the resulting autogenerated class. For example, if you have @Register directive, the compiler adds assembly dependencies; in your @Page directive, if you have Debug=”True,” the compiler ensures that you have sufficient rights.
In any event, during this processing of the directives, which can be found in the ProcessDirective() method of the TemplateParser, TemplateControlParser, and PageParser classes, the PageParser class checks to see if the ValidateRequest attribute has been added to the @Page directive, and assigns a Boolean member variable the result of this attribute (or True, if the attribute it omitted). When the compilation actually occurs via the PageCompiler, TemplateControlCompiler, and BaseCompiler classes, the PageCompiler's BuildFrameworkInitializeMethodContents() method injects a call in the autogenerated class to Request.ValidateInput(), which does the request validation check and throws the HttpRequestValidationException, if needed.
Since this line of code is literally added to the autogenerated ASP.NET page prior to the page even running, I don't see a way on how to programmatically suspend Request Validation on a given page. Does anyone else see any workarounds? Initially I thought it might be possible to somehow HTML encode the received input in, say, the Initialization stage of the page lifecycle, hoping beyond hope that the call to Request.ValidateInput() didn't come until after Initialization, but, alas, the call comes in the Instantiation stage, which preceeds Initialization. One possible option might be to have the custom control emit a bit of client-side JavaScript that HTML encodes the control's input prior to the Web Form being submitted. Any other ideas?