我创建了一个接受 HTTP 触发器的小型 Python 程序并将其上传到 Google Cloud Functions。当我发出正文小于 10KB 的 POST 请求时，它工作正常。

但是，当我超过此值时，该函数无法工作并在其响应中发送错误代码 413（请求实体太大）。有什么我可能会丢失的吗？当我阅读配额文档页面时，它说 Google Cloud Functions 应该允许高达 10MB 的请求，这显然比我发送的要多得多。

谢谢。

编辑：

解析POST数据的Python代码如下：

下面提供了显示错误的 Postman 请求屏幕截图：

我的 REST API 有时需要返回413 'Payload too large'响应。

作为上下文：我将 AWS 与 API Gateway 和 Lambda 一起使用。Lambda 的最大有效负载为 6Mb。有时 - 不到 0.1% 的请求 - 负载大于 6Mb，我的 API 返回 413 状态。

我处理这个问题的方法是提供一种从 API 请求数据的替代方法 - 作为一个 URL，该 URL 链接到存储为 S3 上的 json 文件的数据。S3 位于具有生命周期规则的存储桶中，该规则会在短时间内自动删除文件。

这工作正常，但具有不令人满意的特性，即大负载请求会导致客户端进行 3 个单独的调用：

1. 向 API 发出标准请求并接收 413 响应
2. 向 API 发出第二次请求以获取存储在 S3 URL 中的数据。asURL=true为此，我在 GET 请求中使用了一个参数。
3. 发出第三个请求以从 S3 存储桶中检索数据

我正在考虑的另一种方法是在 413 响应中嵌入 S3 URL。例如，将其嵌入到自定义标头中。这将避免第二次调用的需要。

我还可以更改方法，使每个请求都作为 S3 URL 返回，但随后 99.9% 的请求将不必要地进行 2 次调用，而不仅仅是 1 次。

这里是否有最佳实践，或者同样需要避免的不良实践？

我在尝试将数据从我的 web 应用程序 (.netfx 4.6.1) 发送到我的 web api (.net core 3.1) 时遇到了 413 问题。在下面的代码中，我发送了一个列表，其中包含图像的字节数据以及构建文件所需的其他数据。预期的输出是返回一个包含新文件的字节数组。不幸的是，在发送请求时我收到一个错误：响应状态代码不表示成功：413（请求实体太大）。

该错误似乎仅在文件开始时才发生，这是有道理的。我所做的研究似乎指向 IIS 中的设置，主要是 maxAllowedContentLength、maxRequestLength 和 uploadReadAheadSize。我尝试将这些值增加到更适合此过程的值，但似乎没有任何效果。我已经为 web 应用程序和 web api 调整了它们，因为我不确定是哪一个导致了问题。

问题出在哪里？在应用程序中、API 中，还是两者兼而有之？我是否缺少其他设置以允许增加尺寸？我发送请求的方式有问题吗？任何帮助表示赞赏。

我有一个结合了 react.js 前端的 node.js 服务器。我有一个表单，要求用户将文件上传到 AWS S3 存储桶。我正在使用 Multer.js 来处理文件上传。我已将默认上传大小设置为最大 10mb。虽然在使用 localhost 进行测试时，只要文件大小低于 10mb，上传文件绝对没有问题。但是，当我尝试从我的 Nginx Web 服务器执行相同操作时，我在尝试上传任何超过 1mb 的内容时收到“413 错误：请求实体太大”。我试图在这里和这里遵循解决方案，但没有运气。

除了我的前端应用程序捕获的 413 错误之外，我没有任何错误输出。

这是我的快速加载程序的代码（引用它是因为我已经在这些代码行上尝试了上面提到的解决方案。）

任何帮助将不胜感激，谢谢！

我知道这个话题已经被讨论过多次，但不幸的是，所提供的解决方案都不适合我。我尝试将大文件（最大 1.5 GB）从客户端控制台应用程序传输到 WCF 服务。但我总是收到 HTTP 错误远程服务器返回了意外响应：（413）请求实体太大。在传输文件内容时。

我在互联网上找到的所有关于将 maxContentLength 和类似配置添加到 web.config 文件的信息。但我假设我在 web.config 左右的错误部分输入了它们。

编辑 26.02.2020 18:35（由于提示和新测试而更新）

根据上面的提示，我在配置文件中添加了一些条目并进行了更多测试。与此同时，我发现了一些事情：

• web.config 中的数字定义了我在几页上阅读的位而不是字节的大小
• 该数字必须是有效的int32 - 因此最大值为2147483647
• 2147483647 位大约是256 MB - 所以可以理解，我的测试文件大约 400 MB 引起了问题

总体而言，如果无法传输大文件 - 至少20-30 MB应该是可能的。对于较大的文件，我会找到其他解决方案。

为了进行更简单的测试，我刚刚创建了一个新的空 WCF 服务和一个控制台应用程序来测试它。

您可以在Google Drive上找到完整的源代码。我还包含了一个 22MB 的测试图像，它无法传输。

与我的第一个问题不同，我现在得到的是 404 错误而不是 413。因此，当请求与服务不匹配时，IIS 会返回 404 而不是之前的 413。对我来说这是一个非常奇怪的行为。

web.config 和 app.config 看起来仍然和以前一样（除了没有实体框架的东西）。

服务器 web.config

客户端 app.config

由于我不是 web.config 配置方面的专家，我假设我只是在 XML 的错误部分添加了配置。任何人都可以为我提供一些帮助，我的 web.config 需要看起来如何，我可以传输更大的文件。

提前致谢

问候马库斯

当我从 Docker 内的 nodejs 应用程序向外部 REST API 发出请求时，我的 413 请求实体太大。

当我在 Docker 之外提出这个请求时，它会正常进行。

我正在使用节点 10.16.0 并没有成功更新到 12.16.1。

Dockerfile：

我正在测试一个将图像文件上传到服务器的 REST Api。

图片太大，超过最大请求体大小，Nginx 拒绝并返回响应 413(Request Entity Too Large)。

Nginx：错误日志

*329 客户端打算发送太大的正文：1432249 字节，客户端：xx.xx.xx.xx，服务器：api.example.com，请求：“POST /images HTTP/1.1”，主机：“api.example.com ”，推荐人：“ https://example.com/posts/create ”

但是，我发现 firefox/chrome 控制台说，

铬：控制台

从源“ https://example.com ”访问“ https://api.example.com/images ”处的 XMLHttpRequest已被 CORS 策略阻止：没有“Access-Control-Allow-Origin”标头出现在请求的资源。

CORS和413错误之间有什么联系吗？此消息来自哪里，为什么？

在我的集群中，有一个服务在通过 POST 请求时返回 413，请求客户端主体大小大于 10MB。由于从集群外部无法访问此服务，我想知道如何增加此设置以防止出现上述错误。

当然，在服务上使用入口配置时，我可以坚持proxy-body-size注解，但不使用入口配置时又如何呢？

我正在尝试通过使用base64进行图像检测从本地上传图像。
并且在本地主机和邮递员中一切正常。
但是在部署之后，我得到了 CROS 错误。

我已经有 cors 中间件了 server.js

cors 中间件在使用 url 获取图像时工作正常，
但是当我尝试使用base64从本地上传图像时，控制台显示：

这是我尝试过的解决方案：

1. cors-任何地方

然后显示413 payload too large。

由于在localhost和postman中测试时没有错误，我发现一些文章说它可能仍然是cors错误。

2. CORS 预检

服务器.js

它显示错误：

3. 删除后credentials: 'include'，它413 payload too large再次显示。

我很困惑......有谁知道如何解决它？谢谢你。

我在docker中运行一个laravel项目，我在amazon s3上上传文件但是当我上传大于5mb的文件时我得到这个错误

1

我已经编辑了 nginx.conf 文件

有人可以解释一下吗？