您当前的位置:首页 > 电脑百科 > 站长技术 > 服务器

nginx解码特殊字符引发400问题处理案例分享

时间:2020-08-07 10:25:33  来源:  作者:

问题背景和现象

公司任务管理使用的是开源的redmine,以前是单机部署(bitnami_redmine),后来由于项目数量、人员数量和任务数量的增加,卡顿问题比较明显,于是改造为基于k8s的分布式集群部署(Nginx+puma)。

改造后有个现象是,wiki标题中,如果包含引号特殊字符,在打开页面时,redmine后台将返回400。

wiki标题如下:

nginx解码特殊字符引发400问题处理案例分享

 

400显示效果如下:

nginx解码特殊字符引发400问题处理案例分享

 

处理办法

方案1:替换数据库中的引号,替换为空

  • 首先查出wiki标题,使用update进行修改。

这里仅为试验,没有使用MySQL的replace函数进行全局替换

nginx解码特殊字符引发400问题处理案例分享

 

  • 之后去掉引用页wiki_content的引号
nginx解码特殊字符引发400问题处理案例分享

 

  • 通过浏览器测试访问正常
nginx解码特殊字符引发400问题处理案例分享

 

小结:

此方案虽然可以通过update … replace … 进行全部替换wikis title字段,但由于redmine wiki页面可以在项目内进行引用(issue和其他wiki均可引用),引用时内容较多,无法区分引号是否需要被替换,所以无法对wiki_contents以及journal_details表进行全局替换

方案2:找到参数丢失的根源

思路大致是先通过对比缩小范围,找到400是哪个节点返回的,之后再进一步分析具体原因。

  • 1.首先看下nginx端是否正常接收到了参数,中文及特殊字符会进行urlencode,我们直接用转码后的结果在kibana中进行搜索
url.original : *%E4%B8%BB%E6%8E%A7%E6%9C%BA%E6%8A%A5%E9%94%99*
nginx解码特殊字符引发400问题处理案例分享

 

可以看到参数到达nginx端时,还是对的,这很有可能是nginx再向后端svc传递时丢失了参数导致。

我们可以通过curl跳过nginx,直接测试svc地址能否正常返回。

  • 2.先复制可以响应200的请求
nginx解码特殊字符引发400问题处理案例分享

 

  • 3.在服务器上跳过nginx直接访问svc地址,url中增加引号字符(%22),同时数据响应状态码-w %{http_code}
nginx解码特殊字符引发400问题处理案例分享

 

从上面的测试可以看出,跳过nginx转发,可以拿到正常的响应结果。

注:简单说明下,此前置nginx由于各类转发问题(比如cdn回源、oss图片转发等)没有使用nginx-ingress-controller暴露k8s集群中的服务,使用的是集群外置nginx。

  • 4.返回400的请求,在rails日志中并没有看到处理过程
nginx解码特殊字符引发400问题处理案例分享

 

  • 5.rails使用的是puma发布,查看puma日志,可以看到转换异常的错误
nginx解码特殊字符引发400问题处理案例分享

 

到这里基本可以定位到问题节点,处于nginx—>puma时,发送的http请求不被puma认可。

而curl发出的请求,是能被puma认可的。

那么区别到底在哪里?nginx发出的请求为何有差异?

查看nginx error日志没有线索,问题到这里已经陷入了困境,难道只能抓包分析下?

  • 6.服务器上使用tcpdump抓包,期间触发两次请求,一次curl svc地址(响应200的),一次curl nginx地址(响应400的)tcpdump -i cnio host 10.10.2.187 -w /tmp/1.pcap
nginx解码特殊字符引发400问题处理案例分享

 

  • 7.从服务器传到本地用wireshark分析
nginx解码特殊字符引发400问题处理案例分享

 


nginx解码特殊字符引发400问题处理案例分享

 

从上面的对比可知,nginx收到浏览器发送的请求后,发现有urlencode后的字符%22,会进行解码后将引号传递到后端。

为何其他中文字符没有解码,唯独解码引号这一个字符?要弄清楚这个问题,需要结合nginx源码看一下。

  • 8.如何避免这个问题?

正常情况下,uri的转义操作在浏览器端已经完成,所以nginx侧的$request_uri肯定是encode后的正确状态,这一点在文章开头中Kibana的access日志中可以看到。我们可以利用这个参数,对location进行特殊处理

修改前的配置如下

location / {
       proxy_set_header Host $http_host;
       proxy_set_header X-Forwarded-Proto $scheme;
       proxy_set_header X-Real-IP  $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_pass http://10.89.0.8/$1;
}

修改后的配置如下

location / {
       proxy_set_header Host $http_host;
       proxy_set_header X-Forwarded-Proto $scheme;
       proxy_set_header X-Real-IP  $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       if ($request_uri ~* ^/(.*)$) {
          proxy_pass http://10.89.0.8/$1;
       }
}
nginx解码特殊字符引发400问题处理案例分享

 

写在后面

nginx内置变量很多,配合location rewrite正则可以满足多种转发场景。

有其他解决思路的朋友可以留言哟~。



Tags:nginx 特殊字符   点击:()  评论:()
声明:本站部分内容来自互联网,转载是出于传递更多信息之目的,内容观点仅代表作者本人,如有任何标注错误或版权侵犯请与我们联系,我们将及时更正、删除,谢谢。
▌相关评论
发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表
▌相关推荐
问题背景和现象公司任务管理使用的是开源的redmine,以前是单机部署(bitnami_redmine),后来由于项目数量、人员数量和任务数量的增加,卡顿问题比较明显,于是改造为基于k8s的分布式...【详细内容】
2020-08-07   nginx 特殊字符  点击:(4)  评论:(0)  加入收藏
最新更新
栏目热门
栏目头条