摘要：开始重现客户端指令其实这次请求的一些猫腻很容易就能发现在中有空格。而在函数中，做的主要事情就是来解析数据包，在解析完成后执行一下回调函数。具体的一些回调函数就不细讲了，有兴趣的童鞋可自行翻阅。如代码片段所示，前文中所对应的函数就是了。

本文首发于知乎专栏蚂蚁金服体验科技。

首先声明，我在“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 协议去请求另一台服务器的时候，单方面被对方服务器断开了连接——并且并没有任何返回。

其实这次请求的一些猫腻很容易就能发现——在 URL 中有空格。所以我们能简化出一条最简单的 CURL 指令：

$ curl "http://foo/bar baz" -v

注意：不带任何转义。

好的，那么接下去开始写相应的最简单的 Node.js HTTP 服务端源码。

"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。

发现了问题之后，就有另一个问题值得思考了：就 Node.js 会出现这种情况呢，还是其它一些 HTTP 服务器也会有这种情况呢。

于是拿小白鼠 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

于是乎，理所当然，我暂时将这个事件定性为 Node.js 的一个 Bug。

认定了它是个 Bug 之后，我就开始了一贯的看源码环节——由于这个 Bug 的复现条件比较明显，我暂时将其定性为“Node.js HTTP 服务端模块在接到请求后解析 HTTP 数据包的时候解析 URI 时出了问题”。

源码以 Node.js 8.9.2 为准。

这里先预留一下我们能马上想到的 node_http_parser.cc，而先讲这几个文件，是有原因的——这涉及到最后的一个应对方式。

首先看看 lib/http.js 的相应源码：

...
const server = require("_http_server");

const { Server } = server;

function createServer(requestListener) {
  return new Server(requestListener);
}

那么，马上进入 lib/_http_server.js 看吧。

首先是创建一个 HttpParser 并绑上监听获取到 HTTP 数据包后解析结果的回调函数的代码：

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 中来的。

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() 函数。

我们在 lib/_http_common.js 中能发现，HTTPParser 的实现存在于 src/node_http_parser.cc 中：

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 了。

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() 了。

class Parser : public AsyncWrap {
  ...

  static void Execute(const FunctionCallbackInfo& args) {
    Parser* parser;
    ...

    Local