此页面由 Cloud Translation API 翻译。

413 请求实体过大 - TooBigBody

<ph type="x-smartling-placeholder"></ph> 您正在查看 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"
      }
   }
}

可能的原因

如果客户端应用发送到 Apigee Edge 的载荷大小是 HTTP 请求大于 Apigee Edge 中允许的限制。

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

原因	说明	适用的问题排查说明
请求载荷大小大于允许的上限	客户端应用作为 HTTP 请求的一部分发送到 Apigee Edge 的载荷大小为超过 Apigee Edge 中允许的限额。	Edge 公有云和私有云用户
请求载荷大小超出允许的上限解压缩	客户端应用作为 HTTP 的一部分以压缩格式发送的载荷大小由 Apigee Edge 解压缩后，发送给 Apigee Edge 的请求数量超出了允许的上限。	Edge 公有云和私有云用户

常见诊断步骤

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

API 监控

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

<ph type="x-smartling-placeholder"></ph> 以拥有的用户身份登录 Apigee Edge 界面适当的角色。
切换到您要在其中调查问题的单位
导航至分析 >API 监控 >调查页面。
选择您观察到错误的具体时间范围。
您可以选择代理过滤器来缩小错误代码的范围。
根据时间绘制错误代码。
选择一个包含错误代码 protocol.http.TooBigBody 的单元格， Status Code（状态代码）413，如下所示：
错误代码 protocol.http.TooBigBody 的相关信息显示为如下所示：
点击查看日志，然后展开失败请求对应的行。然后从 Logs 窗口中，记录如下所示的详细信息：
未压缩

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

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

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

在日志窗口中，请注意以下详细信息：
- 状态代码：413
- 故障来源：proxy
- 错误代码：protocol.http.TooBigBody。
- 请求长度（字节）：15264（约 15kB）
如果故障来源的值为 proxy，即故障代码 值为 protocol.http.TooBigBody，Request Length 为小于 10 MB，则表示来自客户端的 HTTP 请求具有请求的载荷大小小于其压缩格式允许的上限，但是由 Apigee 解压缩时，载荷大小大于允许的限值。

Trace

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

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

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

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

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

请注意以下信息：
- Content-Encoding：gzip
- Content-Length：14969
- 内容类型：application/x-gzip
浏览跟踪记录的不同阶段，并找到失败的位置。
您会在 Request Received from from Client 阶段，如下所示：
请记下跟踪记录中的错误值。上面的跟踪示例显示了以下内容： <ph type="x-smartling-placeholder">
- 错误： 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（分析的数据记录的）阶段，然后点击该阶段。
在 Phase Details 部分中，向下滚动到 Variables Read。
确定变量 client.received.content.length 的值，该值指示： <ph type="x-smartling-placeholder">
- 以未压缩格式发送请求时，请求载荷的实际大小
- Apigee 解压缩后的请求载荷的大小（当载荷为以压缩格式发送。该值始终与允许的上限 (10 MB)。
。 <ph type="x-smartling-placeholder">
</ph> 注意：可能存在Content-Length错误标头，指示错误载荷，而不是请求载荷。对于此错误，我们需要考虑 client.received.content.length 变量中指定的。

未压缩

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

client.received.content.length 变量：15360204

压缩后

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

client.received.content.length 变量：10489856

下表说明了 Apigee 为何会在下方返回 413 错误两种情形（根据 client.received.content.length 变量的值）：

场景	client.received.content.length 的值	失败原因
未压缩格式的请求载荷	约 15 MB	大小 >允许的大小上限为 10 MB。
压缩格式的请求载荷	约 10 MB	解压缩时超出大小限制 <ph type="x-smartling-placeholder"> </ph> 注意：解压缩后，载荷的实际大小可能会远远超过 10 MB。但是，Apigee 会在未压缩文件的大小后立即停止解压缩。数据超过 10 MB 的上限（默认上限），并返回错误消息。

NGINX

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

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

/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
<ph type="x-smartling-placeholder">
</ph> 注意：请将 ORG、ENV 和 PORT# 替换为实际值。
搜索查看在特定时间段内是否存在任何 413 错误（如果问题是否发生过），或者是否有任何请求仍失败， 413。

如果您确实在 X-Apigee-fault-code 匹配项中找到了任何 413 错误， protocol.http.TooBigBody 的值，然后确定 X-Apigee-fault-source.

未压缩

场景 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`

请注意 Request Length: 15264（14.9 K < 允许的限制）

在这种情况下，即使413 请求长度低于允许的上限，因为该请求可能以压缩格式发送，且负载的大小超过使用 Apigee Edge 进行解压缩时存在的限制。

原因：请求载荷大小超过允许的限额

诊断

确定故障代码、故障来源和请求载荷大小 使用 API 监控、跟踪工具或 NGINX 访问日志观察到错误，如情况 1（未压缩）的常见诊断步骤。
如果故障来源的值为 policy 或 proxy，则表示客户端应用发送到 Apigee 的请求载荷大小大于 Apigee Edge 中允许的限制。
验证第 1 步中确定的请求载荷大小。
- 如果载荷大小 >允许的上限是 10 MB，则这就是导致错误的原因。
- 如果载荷大小 <允许的大小上限为 10 MB，那么负载以压缩格式传递转到原因：解压缩后请求载荷大小超出了允许的上限
您还可以验证请求载荷大小是否确实大于允许的上限：10 MB 按照以下步骤检查实际请求： <ph type="x-smartling-placeholder">
1. 如果您无权访问客户端应用发出的实际请求，请前往解决方法。
2. 如果您可以访问客户端应用发出的实际请求，则请执行操作步骤： <ph type="x-smartling-placeholder">
  1. 验证请求中传递的载荷的大小。
  2. 如果您发现有效负载的大小超过了 “允许的上限”，那么这就是问题的原因。

分辨率

转到分辨率。

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

请求载荷是否以压缩格式和请求标头发送 Content-Encoding 设置为 gzip, Apigee 解压缩请求载荷。在解压缩过程中，如果 Apigee 发现负载较大超过 10 MB， <ph type="x-smartling-placeholder"></ph> 超过允许的限值，则它会停止进一步解压缩，并返回响应，立即显示 413 Request Entity Too Large，并显示错误代码 protocol.http.TooBigBody。

诊断

确定故障代码、故障来源和请求载荷大小 了解使用 API 监控、跟踪工具或 NGINX 访问日志观察到的错误，如常见诊断步骤与情景 2（经过压缩）。
如果故障来源的值为 policy 或 proxy，则这表示客户端应用发送到 Apigee 的请求载荷大小较大超过 Apigee Edge 中允许的限制。
验证第 1 步中确定的请求载荷大小。
- 如果载荷大小 >允许的上限是 10 MB，则这就是导致错误的原因。
- 如果载荷大小 <允许的大小上限为 10 MB，那么负载以压缩格式传递在这种情况下，请检查压缩请求载荷。
您可以验证来自客户端的请求是否以压缩格式发送，未压缩大小超过允许的上限，且使用了以下某一选项方法：
Trace

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

如需使用实际请求进行验证，请执行以下操作：
1. 如果您无权访问客户端应用发出的实际请求，请前往解决方法。
2. 如果您可以访问客户端应用发出的实际请求，则请执行操作步骤： <ph type="x-smartling-placeholder">
  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。
消息处理器日志

如需使用消息处理器日志进行验证，请执行以下操作：
<ph type="x-smartling-placeholder">
</ph> 注意：本部分中的说明仅适用于 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，并且 Apigee 会抛出当大小开始超过 10 MB 的大小上限时，出现 RequestTooLarge 错误错误代码为 protocol.http.TooBigBody
  <ph type="x-smartling-placeholder">
  </ph> 注意：即使将请求载荷。唯一的区别在于，TotalRead 将包含该情况下请求负载的实际大小。

分辨率

固定尺寸

方法 1 [推荐]：修复客户端应用，避免发送大于允许的限额

分析特定客户端发送请求 / 载荷大小超出允许的原因如限制中所定义。
如果不合需要，请修改您的客户端应用，使其可以发送请求 / 载荷大小小于允许的上限。

在上面讨论的示例中，您可以传递一个较小的文件，我们假设 test5mbfile（大小为 5 MB）载荷，如下所示：
```
curl https://<host>/testtoobigbody -k -X POST -F file=@test5mbfile -v
```
如果需要，并且您希望发送的请求/载荷超过允许的限制，请转到接下来的选项

签名网址格式

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

对于超过 10 MB 的载荷，Apigee 建议在如示例中的 <ph type="x-smartling-placeholder"></ph> GitHub 上的 Edge Callout: Signed 网址 Generator 示例。

流式

方法 3：使用流式传输

如果您的 API 代理需要处理非常大的请求和/或响应，则可启用在 Apigee 中进行流式处理。

CwC

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

仅当您无法使用任何推荐选项时，才应使用该选项，会导致性能问题。

Apigee 提供了 CwC 属性，可用于提高请求和响应载荷大小限制。如需了解详情，请参阅 <ph type="x-smartling-placeholder"></ph> 在路由器或消息处理器上设置邮件大小限制

限制

Apigee 要求客户端应用和后端服务器发送的载荷大小不得超过为 Request/response size 记录的允许限制 Apigee Edge 限额。

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

如何查看当前限制？

本部分介绍了如何验证资源是否 HTTPRequest.body.buffer.limit 已使用新值对消息处理器进行更新。

在消息处理器计算机上，搜索属性 HTTPRequest.body.buffer.limit（位于 /opt/apigee/edge-message- processor/conf 目录中），并使用以下命令检查设置的值命令：
```
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.limit10m http.properties。

这表示在 Apigee for Private 中配置的请求载荷大小限制 Cloud 存储空间为 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 监控

未压缩

压缩后

Trace

未压缩

压缩后

未压缩

压缩后

NGINX

未压缩

压缩后

原因：请求载荷大小超过允许的限额

诊断

分辨率

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

诊断

Trace

实际请求

消息处理器日志

分辨率

固定尺寸

签名网址格式

流式

CwC

限制

如何查看当前限制？

必须收集的诊断信息