-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RoutingProxy.proxyRequest modifies the options parameter #248
Comments
Could you create a failing test that replicates the issue? |
It would be something along these lines: var options = {
https: {
cert: '--your cert goes here--',
key: '--your key goes here--'
}
};
require('http-proxy').createServer(options, onRouteRequest).listen(443);
var route = {
host: 'www.google.com',
port: 80
};
function onRouteRequest(req, res, proxy) {
proxy.proxyRequest(req, res, route);
require('assert').equal(2 == Object.getOwnPropertyNames(route).length);
} |
I'm not sure what you are trying to say with that code snippet. It not runnable and contains method names not in You mentioned the issue only occurs when you have two proxies? I see only one in that demo. I want to help you, but without an adequate test to replicate the issue, there is little I can do. |
The method name should have been The snippet simplifies my scenario to the barebones without introducing the complexity of a second proxy. The key point is that the |
Without more information, I can make a guess. If you are seeing |
Yes, the issue has a very simple workaround once you identify it. It just took me 4 hours of pulling my hair out before zeroing in on the issue, so I thought a fix in http-proxy could save this time for others. As far as I could tell one place that adds members to the instance is https://github.com/nodejitsu/node-http-proxy/blob/master/lib/node-http-proxy/routing-proxy.js#L87. |
I think I got it now. Maybe we can just create a new object internally and copy all the options props so this won't happen? What do you think? |
Either that or wrap the options I am passing you and make sure they remain immutable while you can add whatever state you need to the wrapper object. The former is probably less intrusive to the code base, the latter probably easier on the garbage collector. |
Yeah, could just clone the options object, like |
Yes, probably better to just clone the object inside http-proxy so that the passed in options don't get modified. |
So the immutability of the https://github.com/nodejitsu/node-http-proxy/blob/master/lib/node-http-proxy/routing-proxy.js#L205-207 should be: if (!this.proxies[key]) {
this.add(clone(options));
} @chjj I'd prefer not to bring the entire |
Node: v0.7.6
http-proxy: v0.8.0 (via NPM)
MacOS
Problem:
RoutingProxy.prototype.proxyRequest modifies the 'options' parameter by adding new properties to the object. This is unexpected and leads to unintended consequences as described below. I was expecting the API to not modify the options parameter.
Scenario:
I have a single node process that runs two reverse proxies on two different TCP ports: an HTTPS->HTTP proxy and HTTP->HTTP proxy. The two reverse proxies use two instances of RoutingProxy, but the data structure that defines routing rules is shared between the two proxies. Specifically, the object instance I pass as 'options' parameter to RoutingProxy.proxyRequest has a global lifetime. What I notice is that whenever the first routing request is HTTPS, the modifications RoutingProxy.proxyRequest makes in the 'options' parameter cause subsequent HTTP routing requests to fail. It appears that the RoutingProxy is picking HTTPS module instead of HTTP to make the outbound request to the backend.
The text was updated successfully, but these errors were encountered: