在Js页面通过POST传递参数跳转到新页面详解
场景
成都创新互联从2013年成立,是专业互联网技术服务公司,拥有项目成都网站制作、成都网站设计网站策划,项目实施与项目整合能力。我们以让每一个梦想脱颖而出为使命,1280元广丰做网站,已为上家服务,为广丰各地企业和个人服务,联系电话:13518219792
最近在工作中遇到一个需求,有个页面 a.vm,对 ajax 请求的结果进行判断后,获取结果里面的数据传递给一个 URL(b.htm),跳转到新的页面 b.htm。
遇到的问题
因为一开始是 GET 请求,所以当传递的数据过大的时候,会报错 nginx 414 request-uri too long
客户端请求头缓冲区大小,如果请求头总长度大于小于128k,则使用此缓冲区
client_header_buffer_size 128k;
请求头总长度大于128k时使用 large_client_header_buffers
设置的缓存区
large_client_header_buffers
指令参数4为个数,128k为大小,默认是8k。申请4个128k。
large_client_header_buffers 4 128k;
当http 的URI太长或者request header
过大时会报414 Request URI too large
或400 bad request
错误
造成这样的原因
cookie中写入的值太大造成的,因为header中的其他参数的size一般比较固定,只有cookie可能被写入较大的数据
请求参数太长,比如发布一个文章正文,用urlencode后,使用get方式传到后台
本次的故障原因是由问题 2 引起的。即当请求头过大时,超过 large_client_header_buffer
时,nginx可能返回 Request URI too large (414)
或者 Bad-request(400)
错误。
当Request line的长度大于large_client_header_buffer
的一个buffer(128k)
时,nginx会返回"Request URI too large" (414)
错误,对应上面的场景2。
请求头中最长的一行也要小于large_client_header_buffer
,当不是Request line的最长行大于一个buffer(128k)时,会返回"Bad-request"(400)
错误,对应上面的场景1。
临时解决办法
修改 nginx 参数
主要是调大以下参数值:
client_header_buffer_size 512k; large_client_header_buffers 4 512k;
但是调大这个值会出现一个问题,当我的服务器腾挪数据量比较大的时候,可能又要修改这样不是一个办法,最终的解决办法就是由 GET 请求方式修改为 POST 请求方式
最终解决办法
使用 jquery.redirect.js 框架来处理这样的情况,主要使用到的函数是 $.redirect
代码如下:
$http({ method: "POST", dataType: "json", contentType: 'application/json', url: url, data: data, }).success(function (data) { if (data.success) { crId = data.data; $scope.errMsg = ""; var url = "/xx.htm?id=" + id; window.location.href = url } else { $scope.errMsg = data.message; $scope.isDisabled = false; $scope.errorCode = data.code; $scope.trv.physics = data.data; if(data.statusCode === -224){ var vms = data.data; console.log("vms: " + vms); $.redirect('/b.htm', {'vms': vms.toString(), 'resource': trv.resource, 'errMsg': $scope.errMsg}); } } }).error(function (data) { alert(data); $scope.isDisabled = false; });
总结
以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作能带来一定的帮助,如果有疑问大家可以留言交流,谢谢大家对创新互联的支持。
分享题目:在Js页面通过POST传递参数跳转到新页面详解
分享地址:http://azwzsj.com/article/jpgcjc.html