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

 

转载Tim_PHPer大神，感谢大神为我们提供帮助

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

   思路一：修改nginx配置

   这是最简单的一个做法，着报错原因是nginx不允许上传配置过大的文件，那么件把nginx的上传大小配置调高就好。

    1、打开nginx主配置文件nginx.conf，一般在/usr/local/nginx/conf/nginx.conf这个位置，找到http{}段并修改以下内容：

client_max_body_size 2m;

   当中的2m修改成你需要的允许文件大小。

   2、修改后，测试nginx配置是否正确

/usr/local/nginx/sbin/nginx -t

 3、测试配置正确后，重启nginx使配置生效 

/etc/init.d/nginx restart

注意:要是以php运行的话，这个大小client_max_body_size要和php.ini中的如下值的最大值差不多或者稍大，这样就不会因为提交数据大小不一致出现错误。

1. post_max_size = 2M

2. upload_max_filesize = 2M

当中的2m修改成你需要的允许文件大小。把当中的2m修改成你第一步设置的大小。

 

   思路二：修改添加友好报错页面

 思路一虽然简单，但是不一定能过项目测试那一关，项目测试就要求不要看到413 Request Entity Too Large这样显示错误，所以我们只好添加友好报错页面咯。

  1、编辑一个简单的htm作为静态友好页面

(注意html文件乱码请用)

2、更改nginx.conf在http定义区域加入：

 fastcgi_intercept_errors on; 

3、nginx的网站conf配置中的server 定义区域加入： 

error_page 413 /413.htm;  

（注意此处413与/413.htm之间不要用等号，否则返回状态码为200而不是413，同时尽量不要 http://www.xxx.com/404.html出错则会跳过该页面） 
4、测试nginx配置是否正确

/usr/local/nginx/sbin/nginx -t

5、如果上一步成功重启nginx 

  /etc/init.d/nginx restart

 

   

 思路三：表单提交之前先用JS判断并且阻止表单提交

  思路二虽然比思路一有进步了一些，但是提醒还是跳转页面了，这样的用户体验并不会好到哪里去，所以最终想到了思路三。上文已经说过，这413报错是来自后端nginx的，nginx的判断虽然比PHP还要早，但是我们可以直接从前端处理呀！想到这里，实现并不难了。可以添加文件上传事件判断，如果文件超过限制的大小，那么就弹出警告框并让提交按钮失效，如果文件没有超过限制大小，就提示大小合适，并且把之前的按钮失效状态取消掉。

   简单的HTML代码：

3. 文章展示图片(800KB内):

发布

 

 

  JS代码：

 

1. $('#picture').bind('change', function () {

2. if (this.files[0].size / 1024 / 1024 > 0.8){

3. value = this.files[0].size/1024;

4. alert('该文件大小是 ' + value .toFixed(0) + "KB,已超过大小限制，请修改！");

5. document.getElementById("submit").disabled=true;

6. document.getElementById("submit").innerHTML='非法图片内容';

7. }else{

8. alert('该文件可以提交！');

9. document.getElementById("submit").disabled=false;

10. document.getElementById("submit").innerHTML='提交';

11. }

12. });

总结：其实三个思路是按照时间顺序来写的，在实际项目中最终的功能实现也是更新换代才有了最后的结果。不过当有这样类似的经验，下次遇到这样的弯路就省掉，同时会让自己的处理问题的方式更加成熟。

 

 

原文https://blog.csdn.net/Tim_phper/article/details/51992986