摘要：開始重現(xiàn)客戶端指令其實這次請求的一些貓膩很容易就能發(fā)現(xiàn)在中有空格。而在函數(shù)中，做的主要事情就是來解析數(shù)據(jù)包，在解析完成后執(zhí)行一下回調(diào)函數(shù)。具體的一些回調(diào)函數(shù)就不細(xì)講了，有興趣的童鞋可自行翻閱。如代碼片段所示，前文中所對應(yīng)的函數(shù)就是了。

本文首發(fā)于知乎專欄螞蟻金服體驗科技。

首先聲明，我在“Bug”字眼上加了引號，自然是為了說明它并非一個真 Bug。

昨天有個童鞋在看后臺監(jiān)控的時候，突然發(fā)現(xiàn)了一個錯誤：

[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://..."

大概意思就是說：一臺服務(wù)器通過 HTTP 協(xié)議去請求另一臺服務(wù)器的時候，單方面被對方服務(wù)器斷開了連接——并且并沒有任何返回。

其實這次請求的一些貓膩很容易就能發(fā)現(xiàn)——在 URL 中有空格。所以我們能簡化出一條最簡單的 CURL 指令：

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

注意：不帶任何轉(zhuǎn)義。

好的，那么接下去開始寫相應(yīng)的最簡單的 Node.js HTTP 服務(wù)端源碼。

"use strict";

const http = require("http");

const server = http.createServer(function(req, resp) {
    console.log("?");
    resp.end("hello world");
});

server.listen(5555);

大功告成，啟動這段 Node.js 代碼，開始試試看上面的指令吧。

如果你也正在跟著嘗試這件事情的話，你就會發(fā)現(xiàn) Node.js 的命令行沒有輸出任何信息，尤其是嘲諷的 "?"，而在 CURL 的結(jié)果中，你將會看見：

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

發(fā)現(xiàn)了問題之后，就有另一個問題值得思考了：就 Node.js 會出現(xiàn)這種情況呢，還是其它一些 HTTP 服務(wù)器也會有這種情況呢。

于是拿小白鼠 Nginx 做了個實驗。我寫了這么一個配置：

server {
    listen 5555;

    location / {
        return 200 $uri;
    }
}

接著也執(zhí)行一遍 CURL，得到了如下的結(jié)果：

$ 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

于是乎，理所當(dāng)然，我暫時將這個事件定性為 Node.js 的一個 Bug。

認(rèn)定了它是個 Bug 之后，我就開始了一貫的看源碼環(huán)節(jié)——由于這個 Bug 的復(fù)現(xiàn)條件比較明顯，我暫時將其定性為“Node.js HTTP 服務(wù)端模塊在接到請求后解析 HTTP 數(shù)據(jù)包的時候解析 URI 時出了問題”。

源碼以 Node.js 8.9.2 為準(zhǔn)。

這里先預(yù)留一下我們能馬上想到的 node_http_parser.cc，而先講這幾個文件，是有原因的——這涉及到最后的一個應(yīng)對方式。

首先看看 lib/http.js 的相應(yīng)源碼：

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

const { Server } = server;

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

那么，馬上進(jìn)入 lib/_http_server.js 看吧。

首先是創(chuàng)建一個 HttpParser 并綁上監(jiān)聽獲取到 HTTP 數(shù)據(jù)包后解析結(jié)果的回調(diào)函數(shù)的代碼：

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);
}

從源碼中文我們能看到，當(dāng)一個 HTTP 請求過來的時候，監(jiān)聽函數(shù) connectionListener() 會拿著 Socket 對象加上一個 data 事件監(jiān)聽——一旦有請求連接過來，就去執(zhí)行 socketOnData() 函數(shù)。

而在 socketOnData() 函數(shù)中，做的主要事情就是 parser.execute(d) 來解析 HTTP 數(shù)據(jù)包，在解析完成后執(zhí)行一下回調(diào)函數(shù) 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（效果類似于最簡易的動態(tài)內(nèi)存池），每個 Parser 在初始化的時候綁定上了各種回調(diào)函數(shù)。具體的一些回調(diào)函數(shù)就不細(xì)講了，有興趣的童鞋可自行翻閱。

這么一來，鏈路就比較明晰了：

請求進(jìn)來的時候，Server 對象會為該次請求的 Socket 分配一個 HttpParser 對象，并調(diào)用其 execute() 函數(shù)進(jìn)行解析，在解析完成后調(diào)用 onParserExecuteCommon() 函數(shù)。

我們在 lib/_http_common.js 中能發(fā)現(xiàn)，HTTPParser 的實現(xiàn)存在于 src/node_http_parser.cc 中：

const binding = process.binding("http_parser");
const { methods, HTTPParser } = binding;

至于為什么 const binding = process.binding("http_parser") 就是對應(yīng)到 src/node_http_parser.cc 文件，以及這一小節(jié)中下面的一些 C++ 源碼相關(guān)分析，不明白且有興趣的童鞋可自行去閱讀更深一層的源碼，或者網(wǎng)上搜索答案，或者我提前無恥硬廣一下我快要上市的書《Node.js：來一打 C++ 擴(kuò)展》——里面也有說明，以及我的有一場知乎 Live《深入理解 Node.js 包與模塊機(jī)制》。

總而言之，我們接下去要看的就是 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() 所對應(yīng)的函數(shù)就是 Parser::Execute() 了。

class Parser : public AsyncWrap {
  ...

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

    Local