400 Bad Request

> [本文](https://zhuanlan.zhihu.com/p/31966196)首发于知乎专栏[蚂蚁金服体验科技](https://zhuanlan.zhihu.com/xtech)。首先声明，我在“Bug”字眼上加了引号，自然是为了说明它并非一个真 Bug。 ## 问题抛出昨天有个童鞋在看后台监控的时候，突然发现了一个错误： ``` [error] 000001#0: ... upstream prematurely closed connection while reading response header from upstream. client: 10.10.10.10 server: foo.com request: "GET /foo/bar?rmicmd,begin run clean docker images job HTTP/1.1" upstream: "http://..." ``` 大概意思就是说：一台服务器通过 HTTP 协议去请求另一台服务器的时候，单方面被对方服务器断开了连接——并且并没有任何返回。 ## 开始重现 ### 客户端 CURL 指令其实这次请求的一些猫腻很容易就能发现——在 URL 中有空格。所以我们能简化出一条最简单的 CURL 指令： ```sh $ curl "http://foo/bar baz" -v ``` > **注意：**不带任何转义。 ### 最小 Node.js 源码好的，那么接下去开始写相应的最简单的 Node.js HTTP 服务端源码。 ```js 'use strict'; const http = require('http'); const server = http.createServer(function(req, resp) { console.log('🌚'); resp.end('hello world'); }); server.listen(5555); ``` 大功告成，启动这段 Node.js 代码，开始试试看上面的指令吧。如果你也正在跟着尝试这件事情的话，你就会发现 Node.js 的命令行没有输出任何信息，尤其是嘲讽的 `'🌚'`，而在 CURL 的结果中，你将会看见： ``` $ curl 'http://127.0.0.1:5555/d d' -v * Trying 127.0.0.1... * TCP_NODELAY set * Connected to 127.0.0.1 (127.0.0.1) port 5555 (#0) > GET /d d HTTP/1.1 > Host: 127.0.0.1:5555 > User-Agent: curl/7.54.0 > Accept: */* > * Empty reply from server * Connection #0 to host 127.0.0.1 left intact curl: (52) Empty reply from server ``` 瞧，**Empty reply from server**。 ### Nginx 发现了问题之后，就有另一个问题值得思考了：就 Node.js 会出现这种情况呢，还是其它一些 HTTP 服务器也会有这种情况呢。于是拿小白鼠 Nginx 做了个实验。我写了这么一个配置： ```nginx server { listen 5555; location / { return 200 $uri; } } ``` 接着也执行一遍 CURL，得到了如下的结果： ``` $ curl 'http://127.0.0.1:5555/d d' -v * Trying 127.0.0.1... * TCP_NODELAY set * Connected to 127.0.0.1 (127.0.0.1) port 5555 (#0) > GET /d d HTTP/1.1 > Host: 127.0.0.1:5555 > User-Agent: curl/7.54.0 > Accept: */* > < HTTP/1.1 200 OK < Server: openresty/1.11.2.1 < Date: Tue, 12 Dec 2017 09:07:56 GMT < Content-Type: application/octet-stream < Content-Length: 4 < Connection: keep-alive < * Connection #0 to host xcoder.in left intact /d d ``` ![厉害了，我的 Nginx](http://ww2.sinaimg.cn/bmiddle/a15b4afegy1fmf43teykfj20c80c8ta0) 于是乎，理所当然，我**暂时**将这个事件定性为 Node.js 的一个 Bug。 ## Node.js 源码排查认定了它是个 Bug 之后，我就开始了一贯的看源码环节——由于这个 Bug 的复现条件比较明显，我暂时将其定性为“Node.js HTTP 服务端模块在接到请求后解析 HTTP 数据包的时候解析 URI 时出了问题”。 ### http.js -> _http_server.js -> _http_common.js > 源码以 [Node.js 8.9.2](https://github.com/nodejs/node/tree/v8.9.2) 为准。这里先预留一下我们能马上想到的 **node_http_parser.cc**，而先讲这几个文件，是有原因的——这涉及到最后的一个应对方式。首先看看 [**lib/http.js**](https://github.com/nodejs/node/blob/v8.9.2/lib/http.js#L33-L35) 的相应源码： ```js ... const server = require('_http_server'); const { Server } = server; function createServer(requestListener) { return new Server(requestListener); } ``` 那么，马上进入 **lib/_http_server.js** 看吧。首先是创建一个 HttpParser 并绑上监听获取到 HTTP 数据包后解析结果的回调函数的代码： ```js const { parsers, ... } = require('_http_common'); function connectionListener(socket) { ... var parser = parsers.alloc(); parser.reinitialize(HTTPParser.REQUEST); parser.socket = socket; socket.parser = parser; parser.incoming = null; ... state.onData = socketOnData.bind(undefined, this, socket, parser, state); ... socket.on('data', state.onData); ... } function socketOnData(server, socket, parser, state, d) { assert(!socket._paused); debug('SERVER socketOnData %d', d.length); var ret = parser.execute(d); onParserExecuteCommon(server, socket, parser, state, ret, d); } ``` 从源码中文我们能看到，当一个 HTTP 请求过来的时候，监听函数 `connectionListener()` 会拿着 Socket 对象加上一个 `data` 事件监听——一旦有请求连接过来，就去执行 `socketOnData()` 函数。而在 `socketOnData()` 函数中，做的主要事情就是 `parser.execute(d)` 来解析 HTTP 数据包，在解析完成后执行一下回调函数 `onParserExecuteCommon()`。至于这个 `parser`，我们能看到它是从 [**lib/_http_common.js**](https://github.com/nodejs/node/blob/v8.9.2/lib/_http_common.js#L170-L193) 中来的。 ```js var parsers = new FreeList('parsers', 1000, function() { var parser = new HTTPParser(HTTPParser.REQUEST); ... parser[kOnHeaders] = parserOnHeaders; parser[kOnHeadersComplete] = parserOnHeadersComplete; parser[kOnBody] = parserOnBody; parser[kOnMessageComplete] = parserOnMessageComplete; parser[kOnExecute] = null; return parser; }); ``` 能看出来 `parsers` 是 `HTTPParser` 的一条 Free List（效果类似于最简易的动态内存池），每个 Parser 在初始化的时候绑定上了各种回调函数。具体的一些回调函数就不细讲了，有兴趣的童鞋可自行翻阅。这么一来，链路就比较明晰了： **请求进来的时候，Server 对象会为该次请求的 Socket 分配一个 `HttpParser` 对象，并调用其 `execute()` 函数进行解析，在解析完成后调用 `onParserExecuteCommon()` 函数。** ### node_http_parser.cc 我们在 **lib/_http_common.js** 中能发现，`HTTPParser` 的实现存在于 **src/node_http_parser.cc** 中： ```js const binding = process.binding('http_parser'); const { methods, HTTPParser } = binding; ``` > 至于为什么 `const binding = process.binding('http_parser')` 就是对应到 **src/node_http_parser.cc** 文件，以及这一小节中下面的一些 C++ 源码相关分析，不明白且有兴趣的童鞋可自行去阅读更深一层的源码，或者网上搜索答案，或者我提前无耻硬广一下我快要上市的书《Node.js：来一打 C++ 扩展》——里面也有说明，以及我的有一场知乎 Live《深入理解 Node.js 包与模块机制》。总而言之，我们接下去要看的就是 [**src/node_http_parser.cc**](https://github.com/nodejs/node/blob/v8.9.2/src/node_http_parser.cc#L796-L804) 了。 ```cpp env->SetProtoMethod(t, "close", Parser::Close); env->SetProtoMethod(t, "execute", Parser::Execute); env->SetProtoMethod(t, "finish", Parser::Finish); env->SetProtoMethod(t, "reinitialize", Parser::Reinitialize); env->SetProtoMethod(t, "pause", Parser::Pause); env->SetProtoMethod(t, "resume", Parser::Pause); env->SetProtoMethod(t, "consume", Parser::Consume); env->SetProtoMethod(t, "unconsume", Parser::Unconsume); env->SetProtoMethod(t, "getCurrentBuffer", Parser::GetCurrentBuffer); ``` 如代码片段所示，前文中 `parser.execute()` 所对应的函数就是 `Parser::Execute()` 了。 ```cpp class Parser : public AsyncWrap { ... static void Execute(const FunctionCallbackInfo& args) { Parser* parser; ... Local