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

技术分享 3年前 (2022-11-30) 0 999+

背景

之前在一次不规范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问题：

第一类是之前解决了的nginx可以兼容识别，但golang 网络库无法识别会报400的含空格请求，举例入下:

curl 'http://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"}}

第二类是这次新发现的nginx层直接返回400的含空格请求，并且还发发现该类报错很多都是来源于华为手机，如下可看出其400响应为nginx直接返回：

curl 'http://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再进行使用，这样压根就不会有这么一堆幺蛾子。

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

发表评论