Entity Framework保存超50KB数据触发RequestEntityTooLarge错误求助

核心定位 #

既然IIS事务日志无相关请求记录，说明请求在到达IIS之前就被拦截，或者在ASP.NET管道的极早期阶段被阻断，而非IIS层的配置问题。结合场景描述，重点排查应用层的内部限制，而非传统的IIS请求大小配置。

排查与解决方案 #

1. 实体类数据注解限制（最可能原因） #

检查存储富文本内容或图片数据的实体类字段，是否添加了[StringLength]或[MaxLength]属性限制长度为50KB（51200字节）：

• 错误示例：

  [MaxLength(51200)]
  public string HtmlContent { get; set; }
  
  [MaxLength(51200)]
  public byte[] ImageData { get; set; }
  

• 修正方案：
  移除固定长度限制，改用支持最大容量的配置：

  // 字符串类型对应SQL Server的nvarchar(max)
  [Column(TypeName = "nvarchar(max)")]
  public string HtmlContent { get; set; }
  
  // 二进制图片数据对应SQL Server的varbinary(max)
  [Column(TypeName = "varbinary(max)")]
  public byte[] ImageData { get; set; }
  

  这类限制会在Model绑定阶段触发验证失败，导致请求被提前阻断，不会进入IIS日志记录流程。

2. OData 消息大小限制 #

如果使用OData暴露接口，默认的HttpConfiguration会有消息大小限制，需手动调整：
在OData配置类（通常是WebApiConfig.cs或Startup.cs）中添加以下配置：

public static void Register(HttpConfiguration config)
{
    // 设置最大接收消息大小为2GB
    config.MaxReceivedMessageSize = 2147483647;
    
    // 调整JSON序列化的长度限制
    var jsonFormatter = config.Formatters.JsonFormatter;
    jsonFormatter.SerializerSettings.MaxJsonLength = int.MaxValue;
    jsonFormatter.MaxDepth = null;
    
    // 其他OData路由配置...
}

3. Owin 中间件拦截检查 #

检查Startup.cs中的Owin配置，是否有自定义中间件或第三方组件（如安全、日志类）提前校验了请求大小：

• 查找类似context.Request.ContentLength的判断逻辑，若存在固定50KB的限制阈值，需调整该值。
• 若使用Microsoft.Owin.Host.SystemWeb，确认未通过中间件设置请求大小限制。

4. ASP.NET 全局配置覆盖检查 #

• 检查Web.config中是否存在<location>节点，为特定控制器/Action单独设置了maxRequestLength，覆盖了全局配置：

  <location path="YourEditorController/SaveContent">
    <system.web>
      <httpRuntime maxRequestLength="51200" />
    </system.web>
  </location>
  

  若存在此类配置，需删除或调整阈值。
• 检查服务器的machine.config（路径：C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\machine.config或Framework64对应路径），确认httpRuntime的maxRequestLength未被全局限制为50KB。

5. 客户端/编辑器限制排查 #

使用Fiddler抓包，确认请求是否成功发送到服务器：

• 若请求未发送，检查富文本编辑器的前端配置，是否内置了50KB的上传大小限制。
• 检查前端JS代码，是否在提交前对表单数据大小做了校验拦截。

6. 数据库字段类型验证 #

若采用图片单独存储的方案，确认数据库中图片字段的类型：

• SQL Server需使用varbinary(max)而非varbinary(51200)；
• 其他数据库对应支持大二进制数据的类型（如MySQL的LONGBLOB）。
  错误的字段类型会导致EF保存时抛出异常，可能被包装为请求过大的错误。

调试辅助手段 #

在Global.asax中添加Application_BeginRequest事件，打印请求内容长度，确认请求是否进入ASP.NET管道：

protected void Application_BeginRequest()
{
    var contentLength = Request.ContentLength;
    System.Diagnostics.Trace.WriteLine($"Received request with content length: {contentLength} bytes");
}

• 若能打印日志，说明请求已进入ASP.NET，重点排查Model验证、OData/Owin配置；
• 若无法打印，说明请求未到达ASP.NET，需检查客户端、防火墙或服务器前置代理的限制。

内容的提问来源于stack exchange，提问作者user15622687