此页面由 Cloud Translation API 翻译。

413 请求实体过大 - TooBigBody

您正在查看的是 Apigee Edge 文档。
转到 Apigee X 文档。信息

问题

客户端应用收到 HTTP 状态代码 413 Request Entity Too Large（错误代码为 protocol.http.TooBigBody ），作为 API 调用的响应。

错误消息

客户端应用会获得以下响应代码：

HTTP/1.1 413 Request Entity Too Large

此外，您可能还会看到以下错误消息：

{
   "fault":{
      "faultstring":"Body buffer overflow",
      "detail":{
         "errorcode":"protocol.http.TooBigBody"
      }
   }
}

可能的原因

如果客户端应用作为 HTTP 请求的一部分发送到 Apigee Edge 的载荷大小超过 Apigee Edge 中允许的限制，就会发生此错误。

以下是导致此错误的可能原因：

原因	说明	适用的问题排查说明
请求的载荷大小超出允许的上限	客户端应用在向 Apigee Edge 发出的 HTTP 请求中发送的载荷大小超出 Apigee Edge 中允许的上限。	Edge 公有云和私有云用户
解压缩后的请求载荷大小超出允许的上限	客户端应用在向 Apigee Edge 发出的 HTTP 请求中以压缩格式发送的载荷大小超出 Apigee Edge 解压缩后允许的上限。	Edge 公有云和私有云用户

常见诊断步骤

使用以下工具/技巧之一来诊断此错误：

API 监控

要使用 API Monitoring 诊断错误，请执行以下操作：

以拥有适当角色的用户身份登录 Apigee Edge 界面。
切换到您要调查问题的组织
前往 Analyze > API Monitoring > Investigate 页面。
选择您发现错误的具体时间范围。
您可以选择 Proxy（代理）过滤器以缩小错误代码的范围。
根据时间绘制故障代码。
选择一个包含 Fault Code protocol.http.TooBigBody 和 Status Code 413 的单元格，如下所示：
错误代码 protocol.http.TooBigBody 的相关信息如下所示：
点击查看日志，然后展开失败请求所在的行。然后，在 Logs 窗口中，记下如下所示的详细信息：
未压缩

场景 1：请求以未压缩形式发送的载荷

在“日志”窗口中，请注意以下详细信息：
- 状态代码：413
- 错误来源：proxy
- 错误代码：protocol.http.TooBigBody。
- 请求长度（字节）：15360440（约 15 MB）
如果故障来源的值为 proxy，故障代码的值为 protocol.http.TooBigBody，并且请求长度大于 10 MB，则表示来自客户端的 HTTP 请求的请求载荷大小大于 Apigee 中允许的限制。
压缩后

场景 2：请求以压缩形式发送的载荷

在 Logs 窗口中，请注意以下详细信息：
- 状态代码：413
- 错误来源：proxy
- 错误代码：protocol.http.TooBigBody。
- 请求长度（字节）：15264（约 15kB）
如果故障来源的值为 proxy，故障代码的值为 protocol.http.TooBigBody，并且请求长度小于 10 MB，则表示来自客户端的 HTTP 请求的请求载荷大小低于其压缩格式所允许的限制，但载荷大小超出了 Apigee 未压缩允许的上限。

跟踪记录

如需使用跟踪工具诊断错误，请执行以下操作：

启用跟踪会话，然后：
- 等待 413 Request Entity Too Large 错误发生，或者
- 如果您可以重现问题，请进行 API 调用并重现 413 Request Entity Too Large 错误
确保已启用显示所有流信息。
选择其中一个失败的请求并检查跟踪记录。
进入从客户端接收的请求阶段。
未压缩

场景 1：请求以未压缩形式发送的载荷

请注意以下信息：
- Content-Encoding: 不存在
- Content-Length:：15360204
压缩后

场景 2：请求以压缩形式发送的载荷

请注意以下信息：
- 内容编码：gzip
- Content-Length:：14969
- 内容类型：application/x-gzip
浏览跟踪记录的不同阶段，并找到失败的位置。
您通常可以在 Request Received from Client 阶段之后在数据流中看到错误，如下所示：
记下跟踪记录中的错误值。上面的轨迹示例展示了：
- 错误：Body buffer overflow
- error.class:：com.apigee.errors.http.user.RequestTooLarge
找到 Response Sent to Client，记下跟踪记录中的错误值。以下示例跟踪记录显示了以下内容：
- 错误：413 Request Entity Too Large
- 错误内容： {"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}
进入跟踪记录中的 AX（已记录 Google Analytics（分析）数据）阶段，然后点击该阶段。
在 Phase Details 部分中，向下滚动到 Variables Read。
确定变量 client.received.content.length 的值，该值指示：
- 以未压缩格式发送请求时，请求载荷的实际大小；
- 当请求以压缩格式发送载荷时，由 Apigee 解压缩后的大小。在这种情况下，该值始终与允许的上限 (10 MB) 的值相同。
注意：可能会有 Content-Length 错误标头，它会指示错误载荷的大小，而不是请求载荷的大小。对于此错误，我们需要考虑 client.received.content.length 变量中指定的值。

未压缩

场景 1：请求未压缩形式的载荷

client.received.content.length 变量：15360204

压缩后

场景 2：请求压缩格式的载荷

client.received.content.length 变量：10489856

下表说明了在两种情况下 Apigee 基于 client.received.content.length 变量的值返回 413 错误的原因：

场景	client.received.content.length 的值	失败原因
请求未压缩格式的载荷	约 15 MB	大小 > 允许的上限为 10 MB。
请求压缩格式的载荷	约 10 MB	解压缩后超过了大小限制注意：解压缩后，载荷的实际大小可能会远远超过 10 MB。但是，一旦未压缩数据的大小超过 10 MB（默认限制）的限制，Apigee 就会立即停止解压缩，并返回错误响应。

NGINX

如需使用 NGINX 访问日志诊断错误，请执行以下操作：

如果您是 Private Cloud 用户，则可以使用 NGINX 访问日志来确定有关 HTTP 413 错误的关键信息。
检查 NGINX 访问日志：

/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

注意：请将 ORG、ENV 和 PORT# 替换为实际值。
搜索以查看在特定持续时间内是否存在任何 413 错误（如果问题是在过去发生的），或者是否有任何请求仍然失败并显示 413。

如果您确实发现任何 413 错误，且 X-Apigee-fault-code 与 X-Apigee-fault-code 的值匹配，则确定 X-Apigee-fault-code 的值。

未压缩

场景 1：请求未压缩格式的载荷大小

NGINX 访问日志中的上述示例条目包含 X-Apigee-fault-code 和 X-Apigee-fault-code 的以下值：

响应标头	值
X-Apigee-fault-code	`protocol.http.TooBigBody`
X-Apigee-fault-sourc	`policy`

请注意请求长度：15360440（14.6 MB > 允许的上限）

压缩后

场景 2：请求采用压缩格式的载荷大小

NGINX 访问日志中的上述示例条目具有 X-Apigee-fault-code 和 X-Apigee-fault-code 的以下值：

响应标头	值
X-Apigee-fault-code	`protocol.http.TooBigBody`
X-Apigee-fault-source	`policy`

请注意请求长度：15264（14.9 K < 允许的上限）

在这种情况下，即使请求长度低于允许的限制，Apigee Edge 也会返回 413，因为请求可能是以压缩格式发送的，但载荷的大小超出了 Apigee Edge 解压缩后的限制。

原因：请求载荷大小超出允许的上限

诊断

按照场景 1（未压缩）的常见诊断步骤中所述，确定使用 API 监控、跟踪工具或 NGINX 访问日志观察到的错误的错误代码、故障来源和请求载荷大小。
如果故障来源的值为 policy 或 proxy，则表示客户端应用向 Apigee 发送的请求载荷大小超过 Apigee Edge 允许的限制。
验证请求载荷大小（按照第 1 步确定）。
- 如果载荷大小大于 10 MB 所允许的上限，这就是导致此错误的原因。
- 如果载荷大小小于允许的上限，则请求载荷可能会以压缩格式传递。转到原因：请求载荷大小超出解压缩后允许的限制
您还可以按照以下步骤检查实际请求，以验证请求载荷大小确实大于允许的 10 MB 限制：
1. 如果您无法访问客户端应用发出的实际请求，请转到解决。
2. 如果您有权访问客户端应用发出的实际请求，请执行以下步骤：
  1. 验证请求中传递的载荷大小。
  2. 如果您发现载荷的大小超过 Apigee Edge 中允许的限制，这就是问题的原因。

分辨率

转到分辨率。

原因：请求载荷大小在解压缩后超出允许的上限

如果请求载荷以压缩格式发送，并且请求标头 Content-Encoding 设置为 gzip, ，则 Apigee 会解压缩请求载荷。在解压缩过程中，如果 Apigee 发现载荷的大小大于 10 MB（即允许的上限），就会停止进一步解压缩，并立即返回 413 Request Entity Too Large 并显示错误代码 protocol.http.TooBigBody。

诊断

根据场景 2（压缩）中的常见诊断步骤部分所述，确定使用 API Monitoring、Trace Tool 或 NGINX Access 日志观察到的错误的错误代码、故障来源和请求载荷大小。
如果故障来源的值为 policy 或 proxy，则表示客户端应用向 Apigee 发送的请求载荷大小大于 Apigee Edge 中允许的限制。
验证请求载荷大小（在第 1 步中确定）。
- 如果载荷大小大于 10 MB 所允许的上限，这就是导致此错误的原因。
- 如果载荷大小小于允许的上限，则请求载荷可能会以压缩格式传递。在这种情况下，请检查压缩请求载荷的未压缩大小。
您可以使用以下方法之一来验证来自客户端的请求是否以压缩格式发送，以及未压缩的大小是否超过允许的限制：
跟踪记录

如需使用跟踪工具进行验证，请执行以下操作：
1. 如果您已捕获失败请求的跟踪记录，请参阅 Trace 和
  1. 确定 client.received.content.length 变量的值
  2. 验证来自客户端的请求是否包含 Content-Encoding: gzip 标头
2. 如果 client.received.content.length 变量的值大于 10 MB、允许的限制和请求标头 client.received.content.length ，这就是导致此错误的原因。
实际请求

如需使用实际请求进行验证，请执行以下操作：
1. 如果您无法访问客户端应用发出的实际请求，请转到解决。
2. 如果您有权访问客户端应用发出的实际请求，请执行以下步骤：
  1. 验证请求中传递的载荷的大小以及请求中发送的 Content-Encoding 标头。
  2. 检查载荷的未压缩大小是否超过 Apigee Edge 中允许的限制
    
    示例请求：
    
    curl https://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile.gz -H "Content-Encoding: gzip" -v
    
    在上述示例中，文件 test15mbfile.gz 小于大小限制；不过，未压缩文件 test15mbfile 的大小约为 15 MB，Content-Encoding 标头为 gzip。
    
    如果您使用的是其他客户端，请获取客户端日志以了解发送的载荷大小以及 Content-Encoding 标头是否设置为 gzip。
消息处理器日志

如需使用消息处理器日志进行验证，请执行以下操作：

注意：本部分中的说明仅适用于 Edge Private Cloud 用户。
1. 如果您是 Private Cloud 用户，则可以使用消息处理器日志来确定有关 HTTP 413 错误的关键信息。
2. 检查消息处理器日志：
  
  /opt/apigee/var/log/edge-message-processor/logs/system.log
3. 搜索以查看在特定持续时间内是否存在任何 413 错误（如果问题是在过去发生的），或者是否有任何请求仍然失败并显示 413。
  
  您可以使用以下搜索字符串：
```
grep -ri "chunkCount"
```
```
grep -ri "RequestTooLarge"
```
4. system.log 中的行如下所示（TotalRead 和 chunkCount 可能因您的情况而异）：
```
2021-07-06 13:29:57,544  NIOThread@1 ERROR HTTP.SERVICE -
  TrackingInputChannel.checkMessageBodyTooLarge()
  : Message is too large.  TotalRead 10489856 chunkCount 2570

2021-07-06 13:29:57,545  NIOThread@1 INFO  HTTP.SERVICE -
  ExceptionHandler.handleException()
  : Exception trace: com.apigee.errors.http.user.RequestTooLarge
  : Body buffer overflow
```
5. 在解压缩过程中，只要消息处理器确定读取的总字节数大于 10 MB，它就会停止并输出以下行：
```
Message is too large.  TotalRead 10489856 chunkCount 2570
```
  它意味着请求载荷大小超过 10 MB，当其大小开始超过 10 MB 的上限时，Apigee 会抛出 RequestTooLarge 错误，并且错误代码为 protocol.http.TooBigBody
  
  注意：即使您以未压缩格式发送请求载荷，也会在消息处理器日志中看到上行。唯一的区别在于，在这种情况下，TotalRead 将包含请求载荷的实际大小。

分辨率

修正尺寸

方法 1 [推荐]：修复客户端应用，确保发送的载荷大小不超过允许的上限

分析特定客户端发送请求 / 载荷大小超过限制中定义的允许限制的原因。
如果不希望这样，请修改您的客户端应用，使其发送请求 / 载荷的大小小于允许的上限。

在上述示例中，您可以通过传递一个较小的文件（假设文件为 test5mbfile，大小为 5 MB）来解决此问题，如下所示：
```
curl https://<host>/testtoobigbody -k -X POST -F file=@test5mbfile -v
```
如果需要，并且想要发送的请求/载荷数量超出允许的上限，请转到下一个选项。

签名网址格式

选项 2 [推荐]：在 Apigee JavaCallout 中使用签名网址格式

对于大于 10 MB 的载荷，Apigee 建议在 Apigee JavaCallout 中使用签名网址格式，如 GitHub 上的 Edge 宣传信息：签名网址生成器示例所示。

流式处理

方法 3：使用流式传输

如果您的 API 代理需要处理非常大的请求和/或响应，那么您可以在 Apigee 中启用流式传输。

CwC

方法 4：使用 CwC 属性提高缓冲区限制

仅应在无法使用任何推荐选项时使用此选项，因为如果增加默认大小，可能会导致性能问题。

Apigee 具有 CwC 属性，可用于提高请求和响应载荷大小限制。如需了解详情，请参阅在路由器或消息处理器上设置消息大小限制

限制

Apigee 要求客户端应用和后端服务器发送的载荷大小不超过 Apigee Edge 限制中针对 Request/response size 所述的允许限制。

如果您是公有云用户，则请求和响应载荷大小的上限如 Apigee Edge 限制中的 Request/response size 所述。
如果您是 Private Cloud 用户 ，则可能修改了请求和响应载荷大小的默认限制（尽管不建议这样做）。您可以按照如何查看当前限制中的说明确定请求载荷大小上限。

如何查看当前的上限？

本部分介绍如何验证属性 HTTPRequest.body.buffer.limit 是否已使用消息处理器上的新值更新。

在消息处理器机器上，在 /opt/apigee/edge-message- processor/conf 目录中搜索 HTTPRequest.body.buffer.limit 属性，然后使用以下命令查看已设置的值：
```
grep -ri "HTTPRequest.body.buffer.limit" /opt/apigee/edge-message-processor/conf
```

上述命令的示例结果如下所示：

/opt/apigee/edge-message-processor/conf/http.properties:HTTPRequest.body.buffer.limit=10m

在上面的示例输出中，请注意 HTTPRequest.body.buffer.limit 属性已设置为 http.properties 中的 10m 值。

这表示在 Apigee 中，针对私有云配置的请求载荷大小限制为 10 MB。

如果您仍然需要 Apigee 支持的任何帮助，请参阅必须收集诊断信息。

必须收集的诊断信息

收集以下诊断信息，然后联系 Apigee Edge 支持团队：

如果您是公有云用户，请提供以下信息：

组织名称
环境名称
API 代理名称
用于重现 413 错误的完整 curl 命令
API 请求的跟踪文件

如果您是 Private Cloud 用户，请提供以下信息：

观察到失败请求的完整错误消息
组织名称
环境名称
API 代理软件包
失败 API 请求的跟踪文件
用于重现 413 错误的完整 curl 命令
NGINX 访问日志 /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

其中：将 ORG、ENV 和 PORT# 替换为实际值。
消息处理器系统日志 /opt/apigee/var/log/edge-message-processor/logs/system.log

413 请求实体过大 - TooBigBody

问题

错误消息

可能的原因

常见诊断步骤

API 监控

未压缩

压缩后

跟踪记录

未压缩

压缩后

未压缩

压缩后

NGINX

未压缩

压缩后

原因：请求载荷大小超出允许的上限

诊断

分辨率

原因：请求载荷大小在解压缩后超出允许的上限

诊断

跟踪记录

实际请求

消息处理器日志

分辨率

修正尺寸

签名网址格式

流式处理

CwC

限制

如何查看当前的上限？

必须收集的诊断信息