Inside the new ValidateRequest feature, part II
Note: this entry has moved.
I received a couple of questions by private emails regarding my previous post about ValidateRequest. I believe it may be useful to post them (and the answers!) thus saving me from receiving the same question again J
Q: At which point does the framework call HttpRequest.ValidateInput (if it does so) to force validation on subsequent access to the collections?
A: Yes the fx will call HttpRequest.ValidateInput. This is done by the page parser when generating a new class based on the .aspx file; it overrides the TemplateControl.FrameworkInitialize method to add a call to HttpRequest.ValidateInput (along with other initialization code that exists since the 1.0 bits), i.e.:
[C#]
protected override void FrameworkInitialize()
{
// other init code goes here
this.Request.ValidateInput();
}
Q: Is a collection validated every time it is accessed? Is some caching being done to avoid this?
A: No. Any of the three guarded collections (Cookies, Form, QueryString) will be validated just once. After a collection passes validation, the correspondent bit flag indicating that validation is required (which was previously set by HttpRequest.ValidateInput) is cleared. Further accesses just return the collection without any validation.
Q: Can I force request validation to happen from inside my custom control no matter what value the page developer has set the ValidateRequest attribute to?
A: I believe the best you can do in this case is to call HttpRequest.ValidateInput as soon as possible from your custom control code, for example in your class ctor. This should enforce validation before any event handler coded by the page developer runs. Of course, the ctor for any other control which is located above yours in the control tree hierarchy could actually access these collections without any validation.