Because when you handle a request, you need either respond to it or close it. If you don't close it (e.g: res.end, res.send, ...) the connection remains open. Also all the memory allocated for that request stays around without being collected.

Agree with the point, but remember normal HTTP/1.1 /2 keep alive should close that connection in 15-30 seconds for all modern browsers. It will give rise to a DOS vulnerability as you point out.

But all the objects remain leaked even if the request connection ends. And if the request stream got piped into another stream the problem can become more severe.

Usually error events propagate through piped streams, but that largely depends on the order in which the event handlers were defined.

Are you sure the objects remain leaked when a connection disconnect comes through? I don't have hard data on that.

Depending on the node web framework (express, ...) they may handle that differently and may have timeouts to cleanup.

I'd love to get a firm answer on this one.

I'd love a firm answer too, but I'm too lazy to write up code that puts request objects in a WeakSet and checks for when the set gets smaller. I hope someone else does it. :-)

Yes, I am certain of that. I've seen it in production environments and verified it by looking at heap dumps.