一个有趣的nginx HTTP 400响应问题分析

背景

之前在一次不规范HTTP请求引发的nginx响应400问题分析与解决 中写过客户端query参数未urlencode导致的400问题,当时的结论是:

对于query参数带空格的请求,由于其不符合HTTP规范,golang的net/http库无法识别会直接报错400,而nginx和使用uwsgi与nginx交互的api主服务却可以兼容,可以正常处理。
最终的临时解决方案是:在nginx层根据query 参数是否包含空格决定是转发到golang的log server或api主服务。

本来以为这事就这么结束了,结果最近查询nginx的错误log,居然又发现少部分400错误,最终定位也是因为query 参数包含空格,而且这次报错是直接在nginx层返回400,后面的转发判定逻辑都不会被触发,于是很神奇的发现了两类空格导致的400问题:

  1. 第一类是之前解决了的nginx可以兼容识别,但golang 网络库无法识别会报400的含空格请求,举例入下:
curl '//test.myexample123.com/test?appname=demoapp&phonetype=android&device_type=android&osn=Android OS 10 / API-29 (HONORHLK-AL00/102.0.0.270C00)&osv=Android OS 10 / API-29 (HONORHLK-AL00/102.0.0.270C00)&channel=Google Play&model=HUAWEIHLK-AL00&build=Android OS 10 / API-29 (HONORHLK-AL00/102.0.0.270C00)'
{"status": 1, "data": {"test": "ok"}}
  1. 第二类是这次新发现的nginx层直接返回400的含空格请求,并且还发发现该类报错很多都是来源于华为手机,如下可看出其400响应为nginx直接返回:
curl '//test.myexample123.com/test?appname=demoapp&phonetype=android&device_type=android&osn=Android OS 10 / API-29 (HONORHLK-AL00/102.0.0.270C00)&osv=Android OS 10 / API-29 (HONORHLK-AL00/102.0.0.270C00)&channel=Google Play&model=HUAWEI HLK-AL00&build=Android OS 10 / API-29 (HONORHLK-AL00/102.0.0.270C00)'
<html>
<head><title>400 Bad Request</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx/1.16.1</center>
</body>
</html>

乍看之下其请求参数完全没看出区别,无论哪类问题只要去掉了空格就不会有问题了,难不成nginx对华为手机还有歧视不成(>_<)。

问题定位

两类问题都是由于query参数带空格引起的,最终通过二分法试错确认了其关键区别:如果query参数中包含” H”–即空格+H的组合,nginx层即会直接报错返回400,而如果不包含” H”这一组合,nginx层将能兼容处理–这解释了为何大部分400请求来自华为手机,因为华为手机model参数很多都是”HUAWEI HRY-AL00″这类取值,即包含了” H”这一子串,看起来” H”这个组合在nginx内部有特殊含义,华为手机给撞枪口上了。
那” H”在nginx中到底有什么特殊含义呢?又到了探究源码的时候了,通过拜读源码最终在ngx_http_parse.c 中负责解析http 请求行的ngx_http_parse_request_line 函数中找到了原因,如下

103 ngx_int_t
 104 ngx_http_parse_request_line(ngx_http_request_t *r, ngx_buf_t *b)
 105 {
 106     u_char  c, ch, *p, *m;
 107     enum {
 108         sw_start = 0,
 109         sw_method,
 110         sw_spaces_before_uri,
 111         sw_schema,
 112         sw_schema_slash,
 113         sw_schema_slash_slash,
 114         sw_host_start,
 115         sw_host,
 116         sw_host_end,
 117         sw_host_ip_literal,
 118         sw_port,
 119         sw_host_http_09,
 120         sw_after_slash_in_uri,
 121         sw_check_uri,
 122         sw_check_uri_http_09,
 123         sw_uri,
 124         sw_http_09,
 125         sw_http_H,
 126         sw_http_HT,
 127         sw_http_HTT,
 128         sw_http_HTTP,
 129         sw_first_major_digit,
 130         sw_major_digit,
 131         sw_first_minor_digit,
 132         sw_minor_digit,
 133         sw_spaces_after_digit,
 134         sw_almost_done
 135     } state;
 136
 137     state = r->state;
 138
 139     for (p = b->pos; p < b->last; p++) {
 140         ch = *p;
 141
 142         switch (state) {
 143
 144         /* HTTP methods: GET, HEAD, POST */
 145         case sw_start:
 146             r->request_start = p;
 147
 148             if (ch == CR || ch == LF) {
 149                 break;
 150             }
 ...
 486         /* check "/.", "//", "%", and "\" (Win32) in URI */
 487         case sw_after_slash_in_uri:
 488
 489             if (usual[ch >> 5] & (1U << (ch & 0x1f))) {
 490                 state = sw_check_uri;
 491                 break;
 492             }
 493
 494             switch (ch) {
 495             case ' ':
 496                 r->uri_end = p;
 497                 state = sw_check_uri_http_09; 
 498                 break;
 499             case CR:
 500                 r->uri_end = p;
 501                 r->http_minor = 9;
 502                 state = sw_almost_done;
 503                 break;
 ...
 606         /* space+ after URI */
 607         case sw_check_uri_http_09:
 608             switch (ch) {
...
 618             case 'H':
 619                 r->http_protocol.data = p;
 620                 state = sw_http_H;
 621                 break;
 622             default:
 623                 r->space_in_uri = 1;
 624                 state = sw_check_uri;
 625                 p--;
 626                 break;
 627             }
 628             break;
 ...
 684         case sw_http_H:
 685             switch (ch) {
 686             case 'T':
 687                 state = sw_http_HT;
 688                 break;
 689             default:
 690                 return NGX_HTTP_PARSE_INVALID_REQUEST;
 691             }
 692             break;
 693
 694         case sw_http_HT:
 695             switch (ch) {
 696             case 'T':
 697                 state = sw_http_HTT;
 698                 break;
 699             default:
 700                 return NGX_HTTP_PARSE_INVALID_REQUEST;
 701             }
 702             break;
 703
 704         case sw_http_HTT:
 705             switch (ch) {
 706             case 'P':
 707                 state = sw_http_HTTP;
 708                 break;
 709             default:
 710                 return NGX_HTTP_PARSE_INVALID_REQUEST;
 711             }
 712             break;
 ...

如上ngx_http_parse_request_line函数解析请求行原理为通过for循环逐个遍历字符,内部使用大量switch语句实现了一个状态机进行解析。
当解析到sw_after_slash_in_uri分支的case ‘ ‘(495行)时,会设置状态state=sw_check_uri_http_09,而后在sw_check_uri_http_09分支的case ‘H'(618行)设置state=sw_http_H,而sw_http_H其实是HTTP protocol的解析分支,其负责解析出类似HTTP/1.1 这样的内容,所以在分支sw_http_H(684行)其期待的正确字符应该是HTTP/1.1的 第二个字符T,而后进入case sw_http_HT期待解析HTTP/1.1的第三个字符T,以此类推最终逐个解析完成整个protocol字符串,但是在sw_http_H分支中若没有解析到期望的字符T,其默认行为就是直接返回NGX_HTTP_PARSE_INVALID_REQUEST,也就是400常量了。
简单来说,nginx在解析请求行时,若在query参数中遇到了” H”的组合会导致状态机认为已经进入protocol字段的解析分支,当碰到不识别的字符串则认为格式错误,会直接返回400,而如果query参数中虽然包含未转义空格但却没有” H”组合,nginx的这个请求行解析状态机倒还能够一定程度兼容此类错误,将请求正常转发给upstream server处理。
当然,无论nginx能不能兼容query参数未转义空格,最正确的做法还是客户端应该一开始就保证所有query参数都经过必要urlencode再进行使用,这样压根就不会有这么一堆幺蛾子。

转载请注明出处://www.cnblogs.com/AcAc-t/p/nginx_http_400_for_space_H.html