Description
Version
20.16.0
Platform
Debian 12.6 ARM
Subsystem
No response
What steps will reproduce the bug?
I don't know the reproducible steps - this only occurs when our application is under DOS attack.
How often does it reproduce? Is there a required condition?
Only under high load DOS attack, likely when attacker is rapidly creating/closing connections to the server.
What is the expected behavior? Why is that the expected behavior?
No exception is expected.
What do you see instead?
Error [ERR_HTTP2_INVALID_STREAM]: The stream has been destroyed\n at ServerHttp2Stream.respond (node:internal/http2/core:2784:13)\n at [begin-send] (node:internal/http2/compat:901:19)\n at Http2ServerResponse.writeHead (node:internal/http2/compat:776:21)\n at Http2ServerResponse.writeHead (/src/node_modules/on-headers/index.js:44:26)\n at Http2ServerResponse.writeHead (/src/node_modules/on-headers/index.js:44:26)\n at Http2ServerResponse.writeHead (/src/node_modules/on-headers/index.js:44:26)\n at http2.Http2ServerResponse._implicitHeader (/src/lib/dps-server.js:262:16)\n at Http2ServerResponse.end (/src/node_modules/compression-next/index.js:186:14)
Additional information
Somehow the check to see if the stream has been destroyed here passes, however the subsequent check when trying to actually write to the stream fails here and an exception is thrown. I'm guessing this is perhaps because this[kState].closed is false but the stream's closed property is true?
The one thing that we're doing that may be a contributing factor is that when we detect bad actors we call res.socket.destroySoon() in an attempt to close the HTTP/2 connection. Otherwise, these connections can stay open seemingly indefinitely with lots of parallel requests hitting our server. If you believe this might be causing the above exception we would appreciate an alternative (standard) way of forcing an incoming HTTP/2 socket connection to be immediately terminated.