Hackers are ruthless and they do not care about your site or liabilities. They will try anything. Microsoft has gone a long way to help us, by default, protect against many of these attacks. Which is the way it should be. But there are times when you want your users to submit markup encoded content. Think about when you want your clients, meaning the people paying you do develop and hopefully maintain the application you built, to submit formatted content.
Typically this might be a component that allows them to manage textual content on the site, sort of a content manager scenario, or maybe a 'pretty' product description type thing. I have had many scenarios where I want them to submit formatted text, i.e. HTML. As a side note, just be ready for them to make a mess of a professionally done layout.
One of the common attacks that hackers make against web sites is to submit markup to standard forms in an attempt to perform a cross-site scripting attack or even a SQL Injection attack. If you are not aware of how bad these attacks can be or what they can accomplish just think BAD for you.
When ASP.NET 1.1 was released it included a default filter for these types of attacks. It is sort of generic by not allowing any markup type content to be submitted to a form by default. In fact using anything enclosed in < and > combination will throw an exception to be thrown. But there are scenarios where this type of content should be allowed. Here is my disclaimer though, you should be careful as to when you open up your site to allow this. I typically only allow this type of input in the authenticated administrative sections of my sites.
When a hacker tries to submit a piece of markup the site will throw an System.Web.HttpRequestValidationException exception. The message will also include a piece of the potentially dangerous markup too. This is part of a real error message I got from one of my sites:
A potentially dangerous Request.Form value was detected from the client (txtCourseName='...NTERMINE <a href='http://fora...').
Fortunately you can disable this security checking if you need to either at the page or site levels. To manage this feature at the page level you need to set the ValidateRequest Page Directive. You can set it to either True or False. If it is set to False then the security check is bypassed. By default this is set to True.
You can set it at the site level in the web.config file. Realize by doing this you open your entire site up to potential hacks. I cannot stress enough how much I do not recommend doing this for a public Internet site. This can be controlled as an attribute of the pages element of the system.web element. For more info on the Pages Element check out this explanation of the pages attributes.
So use this with caution, but realize if you get this error what is happening.