• 一个有趣的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 '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"}}
    
    1. 第二类是这次新发现的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)'
    
    <head><title>400 Bad Requesttitle>head>
    <body>
    <center><h1>400 Bad Requesth1>center>
    <hr><center>nginx/1.16.1center>
    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

  • 相关阅读:
    Dotar(zsh,tmux,vim,ag)
    51单片机ADC模数转换
    Linux(ubuntu) 安装kotlin
    ASCII码与字符对照表(附转换代码)
    爬虫基础与人工智能基础
    二十行Python代码,带你了解扣扣发生大规模账号泄露前因后果
    怎么理解flink的异步检查点机制
    Docker Compose介绍和安装
    【Unity】Entities 1.0 学习(一):Aspect
    深入研究一下mysql
  • 原文地址:https://www.cnblogs.com/AcAc-t/p/nginx_http_400_for_space_H.html