问题标签 [http-status-code-413]

我在 etc/nginx/nginx.conf 上将 client_max_body_size 更改为 100M，在 etc/php5/fpm/php.ini 上将 upload_max_filesize 更改为 100M，在 etc/php5/fpm/php.ini 上将 post_max_size 更改为 100M，但我仍然无法获得文件上传工作。

有没有其他人遇到过这个问题？

我正在尝试使用 API v2 /upload 端点将文件上传到 Dropbox。有时我会从 Dropbox 服务器收到 413 错误响应（请求实体太大）。

不幸的是，文档中没有描述最大文件大小，也许有人知道吗？

我在 nginx-unicorn 设置上运行 Rails 3.2 应用程序，当我尝试上传 1MB 或更大的文件（使用 dropzonejs）时，我收到“413 Request Entity too large”错误。我尝试更改 nginx.conf 文件以增加：

但是在重新启动服务器后，我在尝试上传 6.9Mb 文件时遇到了同样的错误。

谷歌搜索似乎指向增加“client_max_body_size”，但它似乎不起作用。

这是 nginx.conf

我不知道下一步该去哪里。任何帮助将不胜感激，谢谢！

用 php5 运行 apache2.2。试图上传一个 1.9MB 的图像文件并且正在获取Error 413 Request Entity Too Large. 尝试了到目前为止我能找到的所有可能的设置，但仍然给我这个错误，有人能想到我还缺少什么吗？

• SSLRenegBufferSize 2147483647
• SSLVerifyClient 需要
• 限制请求体 2147483647
• post_max_size = 1536M
• upload_max_filesize = 1536M
• phpinfo() 显示配置的值

忽略那些巨大的数字，我还缺少什么/在哪里？啊

我在 WCF 4.0 上遇到 413 Request Entity Too Large 错误。

这是服务器 web.config 文件：

这是客户端 web.config 文件：

当我启动这部分代码时：

我得到了错误。但是，当我在该部分添加注释行并使用较小的字符串执行 MyMethod 方法时，使用大字符串的第二种方法有效，WCF 可以处理它。

您知道为什么当我在具有大数据的方法之前添加另一种方法时，413 Error Request Entity Too Large 会消失吗？

是否有必要使用诸如“CallMeBeforeAnyOtherCall()”之类的虚拟方法来启动 WCF 连接？

提前致谢

我目前正在尝试为使用 Dropbox Core API 时刚刚通过我的应用上传的 pdf 文件创建共享链接。

代码如下：

注意事项：

1. PDF 文件大小为 11MB，我可以使用 API 成功轻松地将文件上传到 Dropbox。
2. 仅当我尝试为最近上传的 11MB 文件创建共享链接时才会出现此问题。
3. 另请注意，我正在使用 Node.JS 上传和创建共享链接。

错误：

我得到的错误是 HTTP 错误 413，根据我的研究，这意味着“请求实体太大”

下面是错误的图像，它不是整个图像，因为错误太长：

通过 API 上传的最大文件大小为 150MB，我的文件位于该行下方。是否有用于生成共享链接的单独文件大小？

笔记

我测试了大小为 1MB 到 2MB 的小文件，并成功生成了共享链接，大文件出现问题，即（11MB）

我们有一个使用 http 绑定的应用程序，该绑定在客户端具有此配置：

而服务器端的这个配置：

客户端通过创建 ChannelFactory 然后调用 CreateChannel 来打开通道：

有时，当我们尝试通过此连接传输大文件时，我们会从服务器收到错误消息：“远程服务器返回了意外响应：(413) 请求实体太大。” 我说有时是因为似乎有许多时间/速度因素会导致错误来来去去。例如，错误似乎在具有高带宽的机器上更为普遍。在建立连接后很好地开始时，它们似乎不太普遍。然而，时间/速度的影响是不一致的。

如果 TLS 关闭，我们永远不会有任何问题。

我们对连接进行了 Wire Sharked，发现客户端在错误发生的大约同一时间在端口上发送“FIN”消息，但我们不知道确切的 413 错误何时发生，因为我们没有看到它线鲨。所以，我们不知道这是因还是果。

我们还查看了来自 IIS 的 Failed Request Tracing 信息，发现“请求实体太大”与当时正在传输的数据一起列出，但我们不确定如何解释我们看到的内容。

我们不知道为什么客户端发出 FIN？这正常吗？是服务器上“请求实体太大”错误的原因，还是相反。还是只是巧合？无论哪种方式，效果都是我们必须在那时重新启动文件传输。有什么想法可能是错误的根本原因吗？

在此先感谢您的帮助。

我正在制作一个练习网络服务（客户端的画册展示网站），客户端可以将画册图像上传到服务器。

但是当客户端上传太多图片时出现以下错误

我尝试添加client_max_body_size 100M;nginx.conf

并尝试：

并重试

但仍然得到

有人可以帮忙吗？

我在IIS中托管了asp.net web api应用程序。这个应用程序有 100mb和. 但有时客户会响应非常小的请求。我看到了一些修复，例如“只需更改 uploadreadaheadsize”。但实际上对我来说这个解决方案并不清楚。为什么在正确配置请求限制时会遇到此错误？更新 1：更多细节 - 此应用程序使用客户端证书身份验证。更新 2：我发现了这个https://technet.microsoft.com/en-us/library/cc737382(v=ws.10).aspx<httpRuntime maxRequestLength=...<requestLimits maxAllowedContentLength=...413 Request entity too large

我正在使用托管在 IIS6 中的用 c# 编写的 ASP.Net WEB API。当对 API 进行 POST 时，它会返回 HTTP 状态 413。只要正文中的内容在 32+KB 左右，API（不是 WCF）就会返回响应。如果大小是 40 KB，那么它会出错。

下面是消费者端的代码片段

我正在使用 IIS6 。客户端上的 IIS / 代码更改中是否有任何设置可以帮助我解决此问题？