Как правильно терминировать большие POST-запросы в node.js?

Ну так req.destroy() его и уконтрапупливает, не?

дядь ты лучше попробуй и нам расскажи, че спрашиваешь, вон аж два варианта предложил сразу сам.

also chto uje ddosyat?

С нодой дела не имел, но имел опыт прерывания большого POST-запроса)

Просто ты ведь в курсе, что не все HTTPS-прокси умеют правильно обрабатывать ту ситуацию, когда ответ, пусть даже отрицательный, возвращается раньше, чем успевает прочитаться весь входной поток?

Обычно со стороны клиента это выглядит так, что HTTPS-прокси-сервер просто сбросил (reset) соединение TCP/IP.

Конечно, это больше вопрос к писателям этих HTTPS-прокси-серверов, но если у тебя такой прокси-сервер, то не один фиг, как ты там сбросишь соединение на стороне ноды?)

Хотя у меня большое подозрение, что nginx умеет-таки правильно обрабатывать эту ситуацию, но это сильно зависит от кривизны рук девопосов, которые будут настраивать nginx. Мне везло не всегда)

Ну я потому и спрашиваю, что хочу знать как сделать лучше всего, и с учетом специфики нодовского апи.

Наверняка я не первый, кому подобное нужно.

Слышал, что обычно такие вещи решаются на прокси сервере (nginx, apache, etc.).

Не знаю специфики Node.js, но тут обсуждение от 2011 запиливания этой фичи в stdlib Go: https://github.com/golang/go/issues/2093

Ну, учитывая то, что ты в TOP-200 лучших джаваскриптеров в мире по версии GitLance, может, и ты и первый (по крайней мере, в рунете), кому подобное интересно и нужно.

А по сабжу - если совсем дело отчаянно, то, может, задать вопрос сюда: https://github.com/nodejs/node/issues и оформить pull request к документации для тех, кто следом упрется в тот же вопрос?

Код этих функций на JS я не нашел, видать, нативные. В репозитории ноды есть, правда, тесты на них...

https://github.com/nodejs/node/blob/81fef918d5a8a9aa297b78ade5e58d6caa3176e6/...

Можно с контрибьюторами лично попробовать связаться и поспрашивать....

Разве фильтровать тяжёлые запросы это задача приложения? Как правильно заметил анонимус, почему бы не делать это через nginx?

Вы уже, скорее всего, нагуглили опции в body-parser

app.use(bodyParser.urlencoded({limit: '50mb', extended: true}));

Запрос может требовать валидации. Бывает иногда разумно забраковать всю форму, например, еще до начала выгрузки большого файла. Да и от крякеров тоже валидация может помочь. Так что, зависит от задачи

Ну это уже вопрос скорее к форм ридеру.

А бывает так, что мы начали обрабатывать входящий запрос и тут же открыли соединения с другими серверами. Пока обрабатывается исходный запрос, идет общение с теми другими серверами. Притормаживает клиент - тормозится обмен с серверами. Стриминг называется. И где здесь уровень ридера, а где уровень приложения? Все не так однозначно

и тут же открыли соединения с другими серверами

Что мешает читать текущий стрим и парсить форму(тем более в ноде формпарсеры могут работать без буферизации), при этом можно сразу писать в другой стрим(к примеру на удаленные сервера)?
Вопрос реализации.
Здесь же мне кажется задача не для приложения. Как ты выше предложил nginx в режиме прокси с этим справится(client_max_body_size, не?).

В nginx это тоже будет настроено. Но бывают мелкие проекты где в nginx нет смысла. Например фонтелла прекрасно без nginx работает. И мне интересно именно как правильно сделать ограничение средствами ноды.