I think you are attacking it from the wrong angle by trying to encode all posted data.
Note that a "<" could also come from other outside sources, like a database field, a configuration, a file, a feed and so on.
Furthermore, "<" is not inherently dangerous. It's only dangerous in a specific context: when writing strings that haven't been encoded to HTML output (because of XSS).
In other contexts different sub-strings are dangerous, for example, if you write an user-provided URL into a link, the sub-string "javascript:" may be dangerous. The single quote character on the other hand is dangerous when interpolating strings in SQL queries, but perfectly safe if it is a part of a name submitted from a form or read from a database field.
The bottom line is: you can't filter random input for dangerous characters, because any character may be dangerous under the right circumstances. You should encode at the point where some specific characters may become dangerous because they cross into a different sub-language where they have special meaning. When you write a string to HTML, you should encode characters that have special meaning in HTML, using Server.HtmlEncode. If you pass a string to a dynamic SQL statement, you should encode different characters (or better, let the framework do it for you by using prepared statements or the like)..
When you are sure you HTML-encode everywhere you pass strings to HTML, then set ValidateRequest="false" in the <%@ Page ... %> directive in your .aspx file(s).
In .NET 4 you may need to do a little more. Sometimes it's necessary to also add <httpRuntime requestValidationMode="2.0" /> to web.config (reference).
I recently came to a similar situation where I needed to register a handler for an event only once. I found that you can safely unregister first, and then register again, even if the handler is not registered at all:
myClass.MyEvent -= MyHandler;
myClass.MyEvent += MyHandler;
Note that doing this every time you register your handler will ensure that your handler is registered only once.
Sounds like a pretty good practice to me :)
Best Answer
The normal entry point for a handler is the ProcessRequest method. However you may have code in the class constructor which puts together some instance values which are expensive to build.
If you specify Reusable to be true the application can cache the instance and reuse it in another request by simply calling its ProcessRequest method again and again, without having to reconstruct it each time.
The application will instantiate as many of these handlers as are need to handle the current load.
The downside is that if the number of instances needed is larger than the instances currently present, they cause more memory to be used. Conversely they can also reduce apparent memory uses since their instance value will survive GC cycles and do not need to be frequently re-allocated.
Another caveat is you need to be sure that at the end of the ProcessRequest execution the object state is as you would want for another request to reuse the object.