Restify versions: v6.2.3 to v5.0.1 (v4.3.1 unaffected)
Node.js version: v6.11.3
This bug affects applications that will through the dependency tree require both restify and express somewhere, for example if you have an express application that uses restify as a client to another service, or is even just a dependency and not used directly. This may affect other http libraries but that has not been tested.
The unexpected behavior I noticed was that req.query was a function when it should be an object within express. This lead to unexplainable behavior that req.query.skip was undefined, even though that query variable exists. An upgrade from v4 of restify to v6 was identified as the cause for this behavior change.
The issue is reproducible with express at version v4.16.2 and restify above v4.3.1. So there is something that was introduced between v4.3.1 and v5.0.1 of restify that broke things. I've been able to reproduce this by running the express tests at https://github.com/expressjs/express/releases/tag/4.16.2 and adding this to the index.js file before running tests:
const restify = require('restify');
module.exports = require('./lib/express');
I have not yet dug into the specific reason as there are many commits between these two releases, and opening this issue in case anyone may have an idea to what's causing this before digging through the commits.
This may be a result of global modifications to Request.prototype at https://github.com/restify/node-restify/blob/master/lib/request.js#L414 ?
Okay, so the difference is that ./lib/index.js in v4.3.1 does not require ./lib/request.js, however in versions above and equal to v5.0.1, ./lib/index.js will require ./lib/request.js via ./lib/server.js, that will the set properties on global Request.prototype, which will affect any other library using Request.
@braydonf thank you for the detailed report.
Yes, the issue origins from the fact that the current release of restify extends the core http.IncomingMessage and http.ServerResponse objects and it causes a conflict with express.
At the moment we are co-operating with Node.js maintainers to find an optimal solution.
You can follow the progress here: https://github.com/nodejs/node/pull/15752
Oh hay @braydonf :smile:
Hey @retrohacker, it's been a bit!
Duplicate of: https://github.com/restify/node-restify/issues/1540
@hekike #1540 is this issue ;)
@hekike Please reopen this. It was closed as a duplicate of itself.
You are absolutely right, apologies for it. I wanted to link something else here and keep this issue open.
The good news is that the required change in Node.js was merged in the meantime and released:
Restify's Request and Response objects could be passed as IncomingMessage and ServerResponse to http.createServer instead of extending them.
@hekike is there any plans to patch restify to make use of your update to http.createServer?
Hi @hekike, Is there any chance you could give an example of your workaround? How would one get an instance of restify.Request object to pass into http.createServer? Here's an example that does not work because restify.Request is not defined by require('restify').
const restify = require('restify');
// ....
const restifyRequest = restify.Request;
const server = http.createServer({
IncomingMessage: restifyRequest
}, app);
Most helpful comment
You are absolutely right, apologies for it. I wanted to link something else here and keep this issue open.
The good news is that the required change in Node.js was merged in the meantime and released:
https://nodejs.org/dist/latest-v10.x/docs/api/http.html#http_http_createserver_options_requestlistener
Restify's
RequestandResponseobjects could be passed asIncomingMessageandServerResponsetohttp.createServerinstead of extending them.