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

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

首先聲明，我在“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