每当用户在我的web应用程序中的页面中发布包含<或>的内容时，我都会引发此异常。
我不想因为有人在文本框中输入了字符而引发异常或使整个web应用程序崩溃，但我正在寻找一种优雅的方式来处理这一问题。
捕获异常并显示
出现错误，请返回并重新键入整个表单，但这次请不要使用<
我觉得不够专业。
禁用后验证（validateRequest=“false”）肯定可以避免此错误，但这会使页面容易受到许多攻击。
理想情况下：当发生包含HTML限制字符的回发时，表单集合中的回发值将自动进行HTML编码。因此，我的文本框的.Text属性将是<；html>；
有没有办法让我从处理者那里做到这一点？
当前回答
对于ASP.NET 4.0，您可以将标记全部放在＜location＞元素中，从而允许标记作为特定页面的输入，而不是整个站点的输入。这将确保所有其他页面都是安全的。您不需要在.aspx页面中放入ValidateRequest=“false”。
<configuration>
...
<location path="MyFolder/.aspx">
<system.web>
<pages validateRequest="false" />
<httpRuntime requestValidationMode="2.0" />
</system.web>
</location>
...
</configuration>
在web.config中控制这一点更安全，因为您可以在站点级别看到哪些页面允许标记作为输入。
您仍然需要在禁用请求验证的页面上以编程方式验证输入。
其他回答
我找到了一个使用JavaScript编码数据的解决方案，数据在.NET中解码（不需要jQuery）。
使文本框成为HTML元素（如文本区域）而不是ASP元素。添加隐藏字段。将以下JavaScript函数添加到标头中。函数boo（）{targetText=document.getElementById（“HiddenField1”）；sourceText=document.getElementById（“userbox”）；targetText.value=转义（sourceText.innerText）；}
在文本区域中，包含一个调用boo（）的onchange：
<textarea id="userbox" onchange="boo();"></textarea>
最后，在.NET中，使用
string val = Server.UrlDecode(HiddenField1.Value);
我知道这是单向的-如果你需要双向的，你必须要有创造性，但如果你不能编辑web.config，这就提供了一个解决方案
下面是我（MC9000）通过jQuery创建并使用的示例：
$(document).ready(function () {
$("#txtHTML").change(function () {
var currentText = $("#txtHTML").text();
currentText = escape(currentText); // Escapes the HTML including quotations, etc
$("#hidHTML").val(currentText); // Set the hidden field
});
// Intercept the postback
$("#btnMyPostbackButton").click(function () {
$("#txtHTML").val(""); // Clear the textarea before POSTing
// If you don't clear it, it will give you
// the error due to the HTML in the textarea.
return true; // Post back
});
});
以及标记：
<asp:HiddenField ID="hidHTML" runat="server" />
<textarea id="txtHTML"></textarea>
<asp:Button ID="btnMyPostbackButton" runat="server" Text="Post Form" />
这很有效。如果黑客试图绕过JavaScript发帖，他们只会看到错误。您还可以将所有这些编码的数据保存在数据库中，然后（在服务器端）对其进行解析，并在其他地方显示之前分析和检查攻击。
我知道这个问题是关于表单发布的，但我想为在其他情况下收到此错误的人添加一些详细信息。它也可能发生在用于实现web服务的处理程序上。
假设您的web客户端使用ajax发送POST或PUT请求，并向web服务发送json或xml文本或原始数据（文件内容）。因为web服务不需要从Content-Type头中获取任何信息，所以JavaScript代码没有将此头设置为ajax请求。但如果您没有在POST/PUT ajax请求上设置此标头，Safari可能会添加此标头：“Content-Type:application/x-www-form-urlencoded”。我在iPhone上的Safari 6上观察到了这一点，但其他Safari版本/OS或Chrome可能也会这样做。因此，当接收到此Content-Type标头时，.NETFramework的某些部分假定请求体数据结构对应于html表单发布，而不是html表单发布，并引发HttpRequestValidationException异常。显然，要做的第一件事是在POST/PUT ajax请求中始终将Content-Type头设置为表单MIME类型以外的任何类型，即使它对web服务没有用处。
我还发现了这个细节：在这些情况下，当代码尝试访问HttpRequest.Params集合时，HttpRequestValidationException异常会出现。但令人惊讶的是，当它访问HttpRequest.ServerVariables集合时，这个异常并没有出现。这表明，虽然这两个集合看起来几乎相同，但一个通过安全检查访问请求数据，另一个则没有。
只要这些字符只是“<”和“>”（而不是双引号本身），并且您在上下文中使用它们，例如＜input value＝“this”/>，您就安全了（而对于＜textarea＞这一个＜/textarea＞，您当然会受到攻击）。这可能会简化您的情况，但要做更多的事情，请使用其他发布的解决方案之一。
在ASP.NET中，您可以捕获异常并采取措施，例如显示友好消息或重定向到另一个页面。。。此外，您还可以自行处理验证。。。
显示友好消息：
protected override void OnError(EventArgs e)
{
base.OnError(e);
var ex = Server.GetLastError().GetBaseException();
if (ex is System.Web.HttpRequestValidationException)
{
Response.Clear();
Response.Write("Invalid characters."); // Response.Write(HttpUtility.HtmlEncode(ex.Message));
Response.StatusCode = 200;
Response.End();
}
}
在我的例子中，使用asp:Textbox控件（asp.net4.5），而不是设置validateRequest=“false”的所有页面我用过
<asp:TextBox runat="server" ID="mainTextBox"
ValidateRequestMode="Disabled"
></asp:TextBox>
在导致异常的文本框上。
