Настоящий node:http и восемь дыр вашего сервера

Перенесём сервер на node:http. Разборщика в нём не будет вовсе: createServer получает функцию, которой запрос приходит уже разобранным — с методом, целью и заголовками. Сервер в прогоне отвечает на два адреса и сам же стучится к себе fetch, чтобы клиент был настоящий. Прогноз: в каком порядке встанут строки сервера и клиента, если оба живут в одном процессе?

import { createServer } from 'node:http';

const server = createServer((req, res) => {
  console.log(`сервер: ${req.method} ${req.url}`);
  if (req.url === '/health') {
    res.writeHead(200, { 'content-type': 'application/json' });
    res.end(JSON.stringify({ ok: true }));
    return;
  }
  res.writeHead(404, { 'content-type': 'text/plain; charset=utf-8' });
  res.end('не найдено');
});

// Порт 0 — свободный порт выбирает система: два запуска подряд
// не спорят за один номер, и занятый 3000 пример не уронит.
server.listen(0, '127.0.0.1', async () => {
  const { port } = server.address();
  const base = `http://127.0.0.1:${port}`;
  console.log(`слушаю ${base}`);

  for (const path of ['/health', '/missing']) {
    const res = await fetch(base + path);
    console.log(`клиент: ${path} → ${res.status} ${await res.text()}`);
  }

  // без close процесс не завершится: открытый сервер держит цикл событий
  server.close(() => console.log('сервер закрыт'));
});

слушаю http://127.0.0.1:<порт>
сервер: GET /health
клиент: /health → 200 {"ok":true}
сервер: GET /missing
клиент: /missing → 404 не найдено
сервер закрыт

Строки чередуются, и это не случайность: сервер печатает свою в самом начале обработчика — то есть раньше, чем клиент дождётся ответа на тот же запрос. Порт в примере нулевой: система выдаёт свободный, и два запуска подряд не спорят за один номер (в записи он закрыт маской). А последняя строка объясняет, почему у сервера вообще есть метод close: пока сокет слушает, процесс не завершится — это дескриптор, который держит цикл событий.

Теперь сверим построчно, во что превратилось то, что вы писали главу. Левый столбец — ваш код, средний — то же самое в node:http.

Две строки таблицы отвечают «ничего», и это главное, что стоит унести из сверки. node:http доводит до конца ровно нижний этаж — байты, голову, тело, соединение — и на этом останавливается. Ни маршрутизатора, ни конвейера в нём нет и не будет: их пишет либо автор приложения, либо фреймворк. Вы написали оба и потому знаете, что внутри Express и Nest на этом месте лежит.

Одну связь стоит проговорить отдельно. req и res — не выдумка модуля HTTP, а те самые потоки из главы про потоки: первый читающий, второй пишущий. Поэтому отдать файл в ответ — это pipeline, а не чтение в память; поэтому у ответа есть drain и противодавление; поэтому обрыв соединения приходит обычным событием потока. Глава 3 писалась ради этой строки: HTTP в Node — это два потока и разборщик между ними.

llhttp — тот самый разборщик, модель которого вы собрали: в node 26.5.0 это версия 9.4.2, её печатает process.versions.llhttp. Он на C и потому быстрый, но цикл у него ваш: копить, пока не собралась голова, потом отмерить тело.

Начнём с испорченных запросов. Первый — вообще не запрос: строка текста, которую кто-то отправил на порт 80. Второй — путь с кириллицей сырыми байтами: в цели запроса разрешён только ASCII, всё остальное клиент обязан закодировать процентами. Третий обещает тело дважды: и длиной, и кусочной передачей. Прогноз: сколько из трёх ваш разборщик отвергнет?

// Разборщик из подложки — тот, что разобрал настоящий POST в http-raw
const parser = new RequestParser();
parser.onRequest = (r) =>
  console.log(`разобрал: метод «${r.method}», версия «${r.version}», цель «${r.target}», тело ${JSON.stringify(r.body)}`);

// три испорченные головы: мусор вместо стартовой строки, сырая кириллица, две длины сразу
parser.feed("кто здесь?\r\nhost: java-script.pro\r\n\r\n");
parser.feed("GET /заметки HTTP/1.1\r\nhost: java-script.pro\r\n\r\n");
parser.feed("POST /notes HTTP/1.1\r\nhost: java-script.pro\r\ncontent-length: 4\r\ntransfer-encoding: chunked\r\n\r\n0\r\n\r\n");

Ни одного. «кто здесь?» стало запросом с методом кто и целью здесь?, а версия — undefined, потому что третьей части в строке не нашлось; маршрутизатор честно поищет такой адрес и ответит 404, будто клиент ошибся дверью. Кириллица прошла как есть: для разборщика это просто символы. А третий запрос показал характер: content-length: 4 велел отмерить четыре байта, и телом стали четыре байта чужого обрамления — 0\r\n\r, начало кусочной передачи.

Отправим настоящему серверу те же две поломки: сырую кириллицу в пути и две длины сразу. fetch для этого не годится — он всё исправит сам и кириллицу закодирует, — поэтому клиент в прогоне открывает сокет через node:net и пишет в него текст запроса руками. Рядом с испорченными едут два целых запроса: обычный GET и тело кусками, про которое речь в следующем разделе. Прогноз: сколько из четырёх запросов дойдёт до обработчика?

import { createServer } from 'node:http';
import { connect } from 'node:net';

const server = createServer(async (req, res) => {
  // тело читаем потоком до конца: печатать его есть смысл только целиком
  req.setEncoding('utf8');
  let body = '';
  for await (const chunk of req) body += chunk;
  console.log(`сервер: обработчик вызван для ${req.method} ${req.url}, тело «${body}»`);
  res.end('ok');
});

// разборщик отказал до обработчика: сюда приходит его ошибка, а не запрос
server.on('clientError', (err, socket) => {
  console.log(`сервер: clientError ${err.code}`);
  socket.end('HTTP/1.1 400 Bad Request\r\nConnection: close\r\n\r\n');
});

// каждый кусок сам объявляет свой размер шестнадцатеричным числом БАЙТ, нулевой — конец
const chunked = (...parts) =>
  parts.map((part) => `${Buffer.byteLength(part).toString(16)}\r\n${part}\r\n`).join('') + '0\r\n\r\n';

// сырой запрос байтами: fetch такое отправить не даст, он сам всё исправит
function send(port, label, raw) {
  return new Promise((resolve) => {
    const socket = connect(port, '127.0.0.1', () => socket.end(raw));
    let answer = '';
    socket.on('data', (chunk) => (answer += chunk));
    socket.on('close', () => {
      console.log(`клиент: ${label} → ${answer.split('\r\n')[0]}`);
      resolve();
    });
  });
}

server.listen(0, '127.0.0.1', async () => {
  const { port } = server.address();
  await send(port, 'обычный GET', 'GET /notes HTTP/1.1\r\nHost: x\r\nConnection: close\r\n\r\n');
  await send(
    port,
    'тело кусками, без длины',
    'POST /notes HTTP/1.1\r\nHost: x\r\nTransfer-Encoding: chunked\r\nConnection: close\r\n\r\n'
      + chunked('тело едет', ' кусками'),
  );
  await send(port, 'кириллица в пути', 'GET /заметки HTTP/1.1\r\nHost: x\r\nConnection: close\r\n\r\n');
  await send(
    port,
    'Content-Length вместе с Transfer-Encoding',
    'POST /notes HTTP/1.1\r\nHost: x\r\nContent-Length: 4\r\nTransfer-Encoding: chunked\r\nConnection: close\r\n\r\n0\r\n\r\n',
  );
  server.close();
});

сервер: обработчик вызван для GET /notes, тело «»
клиент: обычный GET → HTTP/1.1 200 OK
сервер: обработчик вызван для POST /notes, тело «тело едет кусками»
клиент: тело кусками, без длины → HTTP/1.1 200 OK
сервер: clientError HPE_INVALID_URL
клиент: кириллица в пути → HTTP/1.1 400 Bad Request
сервер: clientError HPE_INVALID_TRANSFER_ENCODING
клиент: Content-Length вместе с Transfer-Encoding → HTTP/1.1 400 Bad Request

Два из четырёх. На кириллице и на двух длинах сразу обработчик не вызван ни разу — до него не дошло: разбор сломался раньше, и сервер испустил clientError. Это событие не про ошибку в вашем коде, а про ошибку клиента: вторым аргументом в него приходит сокет, а не запрос, — запроса ведь и не получилось. Коды приходят из llhttp: HPE_INVALID_URL и HPE_INVALID_TRANSFER_ENCODING. Отвечать на них приходится вручную, строкой в сокет: обычного res здесь нет.

Соседние коды вы уже видели: голый перевод строки вместо \r\n даёт HPE_INVALID_VERSION или HPE_CR_EXPECTED — во врезке про перевод строки. Список у llhttp длинный, и каждое имя точнее, чем «400 Bad Request»: по нему видно, на каком именно шаге разбор сказал «нет».

Строгость тут не придирчивость, а отказ гадать. Разборщик, который догадывается, что имел в виду клиент, обязательно догадается иначе, чем тот, кто стоит перед ним или за ним, — а на разнице догадок и живут атаки.

Вторая пара строк прогона — тот случай, который обещала статья про тело: длины в голове нет вовсе. Так отвечают, когда размер заранее неизвестен — ответ считается на ходу, файл ещё пишется. Вместо content-length в голове стоит transfer-encoding: chunked, и дальше каждый кусок сам объявляет свой размер шестнадцатеричным числом байт, а нулевой размер значит конец. В прогоне так и отправлено: 11 — это 17 байт «тело едет», f — 15 байт « кусками». Обработчик получил их уже склеенными, одной строкой: сборкой занялся node:http.

Прогноз: что сделает с теми же байтами ваш разборщик?

// Тот же разборщик, а байты — те, что настоящий node:http склеил в прогоне
const parser = new RequestParser();
parser.onRequest = (r) =>
  console.log(`разобрал: метод «${r.method}», цель «${r.target}», тело ${JSON.stringify(r.body)}`);

// длины нет вовсе: тело едет кусками, каждый со своим размером в шестнадцатеричных байтах
parser.feed(
  "POST /notes HTTP/1.1\r\nhost: java-script.pro\r\ntransfer-encoding: chunked\r\n\r\n"
  + "11\r\nтело едет\r\n"
  + "f\r\n кусками\r\n"
  + "0\r\n\r\n",
);

Тело исчезло, а вместо него появился запрос, которого никто не отправлял. content-length в голове нет, Number(undefined ?? 0) — ноль, тело пустое; запрос отдан наружу, и обработчик увидит POST /notes без тела. Но байты-то остались в буфере — и следующий заход разобрал их как новую голову, где стартовой строкой стал размер первого куска. В маршрутизатор ушли бы два запроса вместо одного.

Отсюда же и отказ на голову с двумя длинами. Сервер, который читает content-length, и сервер, который читает transfer-encoding, видят в одном потоке байтов разные запросы. Поставьте одного перед другим — прокси и приложение — и в эту щель пролезет запрос, которого прокси не видел: его протащили внутри тела (по-английски это называют request smuggling). Поэтому node:http не выбирает одну из двух длин, а отвечает 400: выбор здесь и есть дыра.

Повторяющийся заголовок — обычное дело, и разборщик складывает значения через запятую, как велит RFC 9110. Для accept-encoding это ровно то, что нужно: два заголовка и один с перечислением через запятую значат одно и то же. А для длины тела? Прогноз: что напечатает пример, если content-length придёт дважды.

// Клиент прислал длину дважды — заголовки повторяются законно, и разборщик это знает
const parser = new RequestParser();
parser.onRequest = (r) => console.log(`разобрал: ${r.method} ${r.target}, тело ${JSON.stringify(r.body)}`);

parser.feed("POST /notes HTTP/1.1\r\nhost: java-script.pro\r\ncontent-length: 4\r\ncontent-length: 4\r\n\r\nтест");

const length = parser.head === null ? null : parser.head.headers["content-length"];
console.log(`голова разобрана: content-length = ${JSON.stringify(length)}, число из него — ${Number(length)}`);
console.log(`в буфере осталось символов: ${parser.buffer.length}`);

Строки от onRequest нет ни одной: запрос не собрался. Два заголовка склеились в "4, 4", Number сделал из этого NaN, а cutBody сравнивает с ним накопленные байты — и любое сравнение с NaN ложно, поэтому он честно возвращает «ещё не всё, ждём следующий кусок». Ждать он будет вечно. Клиент не получил ни ответа, ни ошибки; соединение занято, в журнале пусто. Это худшая из поломок: не падение, а молчание.

Настоящий сервер, как вы уже знаете, такую голову не берёт вовсе: 400 и clientError с кодом HPE_UNEXPECTED_CONTENT_LENGTH (перепроверено 22.09.2026 на node 26.5.0). Отказ здесь не придирчивость: он приходит там, где ваш разборщик молчит навсегда. Второй предел — размер самой головы. У вашего буфера его нет: заголовки можно слать, пока не кончится память сервера, и это задача 3. У node:http он есть, и вы его уже видели: maxHeaderSize, 16 КиБ. Имя у поломки такое же говорящее, как у соседей, — HPE_HEADER_OVERFLOW, а ответ 431 Request Header Fields Too Large уходит тоже до обработчика.

Сведём всё, чего вашему серверу не хватает. Список не в укор главе: разборщик, маршрутизатор и конвейер вы написали, и написали верно — просто сервер этим не кончается.

Верхние четыре дыры закрывает не фреймворк, а node:http: они про протокол, и решаются они один раз и для всех. Express, Fastify и Nest берут запрос уже разобранным — их код начинается там, где ваш разборщик заканчивается. Поэтому «переписать свой сервер на node:http» — это не поражение: ваш разборщик был моделью, и он свою работу сделал — теперь вы знаете, за что именно отвечает нижний этаж.

Нижние четыре — и есть фреймворк. В них нет ничего, чего вы не написали бы сами: перевод ошибки в код ответа — это try в нужном месте, конфигурация — разбор окружения, слои — контейнер и список маршрутов, тесты — вызов функции вместо запроса по сети. Фреймворк не даёт новых идей; он даёт то же самое, написанное один раз и одинаково во всех проектах, — а это и есть разница между «работает у меня» и «работает у команды».

Половина части позади, и она была про машину: цикл событий, потоки, байты, HTTP. Вторая половина — про то, как из ваших же кусков собирается каркас: декоратор кладёт маршрут в таблицу, контейнер создаёт объекты, конвейер превращается в стражей и перехватчики. Начнётся это с миниатюры, которая соберёт ваш маршрутизатор и ваш контейнер в одно целое и ответит 200 и 404 уже как настоящий каркас.