Well, this is a truly curious feature.  Yes, Kudos to Microsoft for implementing this security feature by default.  Now the responsibility has always and still does rest with the web developer.  In 1.0, and even back with ASP 2 and 3, the web developer was responsible for validating all input.  Remeber, all input is evil until it has been validated.  I imagine that a lot of beginning ASP.NET developers won’t even know about the request validation feature of ASP.NET 1.1, but recently, I came to blows with this feature.  I searched and searched, but in the end, I just had to turn it off.  Yes, I know, bad stuff.  Well, I had the need to accept script as input.  In particular, I allow site editing, and the user has complete control over the page.  Even ASP.NET code is valid as input, so the user can do whatever with the page.  Only trusted users, mind you.  So ASP.NET balked: “hey, you can input script”.  Anyway, there is no configuring this security feature as far as I know, so in the end I just had to disable the feature.  Now I’m in the habit of validating all input anyway, because rarely is there ever a field that can be just anything.  There is usually at least some restriction, so I’ve always validated my own input.  Well, now I’m accepting script as input. 

Which brings me to the point of my post:  When displaying data from a database, always Server.HtmlEncode(your data).  What if the data contains a little emotiexpression ?  If you didn’t HtmlEncode it, it wouldn’t show up.  Also, this ensures that all the data gets displayed if otherwise it would be interpreted as markup of some sort.  So, Server.HtmlEncode() is your friend.