You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We want to track down and document all instances of express and our core deps monkey-patching Node core, specifically it's the HTTP internals like IncomingMessage and ServerResponse where we do our monkey patching. So far as Im aware at least!
The goal being to collect them in one place, decide how to deal with them, push anything we can to node core or otherwise eliminate them.
This is a stub issue rn, hoping folks can collaborate and report places where we do this so we can track and discuss them. I have an actual write up about these issues, some history, and specifics that I'll dig up and probably edit into this or otherwise link to.
I am aware of specifically on-headerss and the res.writeHead we realized during GHSA-76c9-3jph-rj3q
What else?
Our practice of extending the proto of IncomingMessage and ServerResponse to create our (req, res) also falls into this category
In compression: We do monkey patching on ServerResponse methods: .write, .end, .on, .writeHead (on-headers).
In express-session: We do monkey patching on ServerResponse methods: .end, .writeHead (on-headers).
In connect-timeout: We do monkey patching on ServerResponse methods: .writeHead (on-headers).
In response-time: Monkey patching on .writeHead (on-headers).
In cookie-session: Monkey patching on .writeHead (on-headers).
In morgan: Monkey patching on .writeHead (on-headers).
In on-headers: :( — .writeHead.
In express: We alter the prototype of ServerResponse and IncomingResponse. We could follow a style similar to Fastify: store the original response in a property called .raw, and define methods that call those properties, which would then be passed to the router. This would also help enable HTTP/2, so that middleware doesn’t need to overwrite things to use HTTP/2. Instead, through the compatibility layer and ALPN negotiation, middleware could work normally — similar to how Fastify does it (Probably I didn’t explain very well how to do it, but I hope to share the idea in more detail soon)
Those are the modules I noticed; feel free to comment on where else we do monkey patching.
Reacted by Ulises Gascón, Eddy Wilson, Filip Kudła, ChaeHaejoong, sujal and surajtaghash
Activity
bjohansebas commentedon Aug 9, 2025
Monkey patching
ServerResponsemethods:.write,.end,.on,.writeHead(on-headers).ServerResponsemethods:.end,.writeHead(on-headers).ServerResponsemethods:.writeHead(on-headers)..writeHead(on-headers)..writeHead(on-headers)..writeHead(on-headers)..writeHead.ServerResponseandIncomingResponse. We could follow a style similar to Fastify: store the original response in a property called.raw, and define methods that call those properties, which would then be passed to the router. This would also help enable HTTP/2, so that middleware doesn’t need to overwrite things to use HTTP/2. Instead, through the compatibility layer and ALPN negotiation, middleware could work normally — similar to how Fastify does it (Probably I didn’t explain very well how to do it, but I hope to share the idea in more detail soon)Those are the modules I noticed; feel free to comment on where else we do monkey patching.
wesleytodd commentedon Aug 18, 2025
pillarjs/send#159
jonchurch commentedon Oct 17, 2025
on-finishpatches assign sockethttps://github.com/jshttp/on-finished/blob/d2974f5a18f468ea56f58acb2f6d402f4b5142f0/index.js#L189-L199
h/t matteo