记一次413报错

1、线上有个域名出现一个访问报错:

413 Payload Too Large

这里贴一下关于这个报错的解释:

The 413 (Payload Too Large) status code indicates that the server is
   refusing to process a request because the request payload is larger
   than the server is willing or able to process.  The server MAY close
   the connection to prevent the client from continuing the request.

If the condition is temporary, the server SHOULD generate a
   Retry-After header field to indicate that it is temporary and after
   what time the client MAY try again.

于是条件反射就去改nginx的配置,在相应的server段或location段添加client_max_body_size 100m;然后reload  nginx,发现问题并没有解决。还是报错。

有google了一番,找到关于413 Payload Too Large的解释,发现应该是后端server的问题,就开始去排查后端的服务:

,发现:

Error:request entity too large

https://github.com/expressjs/body-parser#limit

应该是baody-parser,的问题:

bodyParser.json([options])

limit

Controls the maximum request body size. If this is a number, then the value specifies the number of bytes; if it is a string, the value is passed to the bytes library for parsing. Defaults to ‘100kb‘

默认 json  limit的大小100k,我们的json已经130k了,很明显就找到问题所在了。

接下来就是修改:

app.use( bodyParser.json({limit: ‘50mb‘}) );
app.use(bodyParser.urlencoded({
  limit: ‘50mb‘,
  extended: true,
  parameterLimit:50000
}));

2、如果报错为413  request  entity  too large
就应该是nginx的问题了,就需要改nginx的配置,在相应的server段或location段添加client_max_body_size 100m;然后reload  nginx



原文地址:https://www.cnblogs.com/cuishuai/p/8302591.html

时间: 2024-11-15 06:36:45

记一次413报错的相关文章

HTTP 413报错

在php中通过flash上传文件到服务器端时报413错误,原来一直以为是php.ini配置的问题,但是检查了php.ini的配置以后,发现不是php.ini的问题,最后是通过Http Analyzer监控然后发现问题的,在此真的感谢很Http Analyzer. 然后在百度中输入关键字“413 Request Entity Too Large”,发现有一个搜索结果是与Nginx有关的,正好我们服务器的环境也是Nginx,按照此文章中的说明对Nginx的配置做了修改,执行/etc/init.d/n

记hbase list 命令报错zookeeper连接失败

hbase list 命令报错:zookeeper exists failed after 4 attempts $telnet h0082161 2181 Connected to 172.16.82.161.Escape character is '^]'. telnet connect by close foreign. 此时发现telnet h0082161 其他端口均正常,其他机器telnet h0082161 2181正常, 此时进入一个误区,一直在围绕telnet 服务查看,查看/

记一次网站报错File not found.问题

php-fpm解析PHP,"No input file specified","File not found"的问题今天不幸中招了. 大致记录一下几个原因: 1.web根目录下文件不存在. 这个解决方法就不用说了. 2.php-fpm配置问题 有可能是fastcgi.conf的配置问题,也有可能是用php-fpm启动用户造成的权限问题,还有可能是nginx下关于fastcgi的配置问题,具体问题具体分析.

记一次https报错

线上ng出现大量log如下: [crit] 11838#0: *19968441 SSL_do_handshake() failed (SSL: error:2D06D075:FIPS routines:fips_pkey_signature_test:test failure error:2D08E06B:FIPS routines:FIPS_CHECK_EC:pairwise test failed error:1409B02B:SSL routines:SSL3_SEND_SERVER_K

记一次django的诡异报错 Could not parse the remainder: '=' from '='

如题,一个展示日志的功能,调用该模板文件时报错,Could not parse the remainder: '=' from '='.这行模板语言在上面出现过同样的,仅仅是改了'<='右端的整数大小,而且该有的标签也不少. 百般思考无解,stackoverflow和百度都没答案.后来重新看了下开发文档,发现是Django的版本不对,开发时用的1.8.2,我部署时用的1.11.5.重新安装低版本的django后问题解决.但原因仍待查. 记一次django的诡异报错 Could not parse

随记(十)--&#39;xxx&#39; does not contain bitcode报错

1 ld: '/Project_now/XZDClub/ZBarSDK/ZBar/libzbar.a(config.o)' does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. for archit

dnmp(docker的lnmp)安装WordPress之后图片上传问题 问题:图片上传大小问题解决和 报错413 Request Entity Too Large

首先是提示超过图片尺寸和大小, 最后发现都是图片大小的问题, 需要修改php的最大上传size 修改之后查看php配置  已经生效  但是还是报错, 提示返回不是合法的json,  查看控制台, 报错是问题:413 Request Entity Too Large  发现是Nginx的配置, 有盖配置. dnmp环境  php配置  直接重新 docker-compose up --build  就可以生效 nginx 需要 停止 删除 重新build才可以, 注意, 停止删除容器, build

三个思路解决413 Request Entity Too Large报错处理

最近一个项目当中,要求上传图片,并且限制图片大小,虽然在laravel当中已经添加了相关的表单验证来阻止文件过大的上传,然而当提交表单时,还没轮到laravel处理,nginx就先报错了.当你仔细看报错页面时,你会发现有nginx版本信息,经过分析,这报错是因为nginx的默认上传文件大小配置client_max_body_size只有2MB, 基于nginx验证比laravel验证要早,想要友好报错而不是直接显示413 Request Entity Too Large,那么就有三个思路去解决.

记一次rsync日志报错directory has vanished

中午两点的时候邮件告知rsync同部svn源库失败,看rsync日志报错显示如上,当时还在上课,没在公司,怀疑是不是有人动了svn的版本库,后来询问同事并通过vpn登录服务器上查看版本库是正常的,也没有同事反应svn有问题,后来看邮件通知都是正常的,后来查资料说是在同步的过程中,正好有人执行了删除文件的操作,要不要这么巧,不知道是不是这个原因,有知道的小伙伴请联系我:528634141,资料显示如下: Can you ensure, that there is no traffic on the