4 ms·
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. A
by partycoder 9y ago
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.
- aeronautic 9y agoAgree 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.
- partycoder 9y agoBut 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.
- aeronautic 9y agoAre 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.
- partycoder 9y agoYes, I am certain of that. I've seen it in production environments and verified it by looking at heap dumps.
- brlewis 9y agoI'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. :-)