-
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
Document forward
vs. target
#773
Comments
Citation from damonmcminn's an answer;
|
+1, the documentation should definitely explain the difference between |
+1 on putting this:
in the readme. |
#917 |
I had to look to find this post, it's istll unclear in the doc right now. |
it's 2018.9.12 |
It seems "forward" does not send the response back to the requesting side. In fact, docs says exactly that:
Note, the Source code follows the docs (from /node-http-proxy/lib/http-proxy/passes/web-incoming.js): if(options.forward) {
// If forward enable, so just pipe the request
...
if(!options.target) { return res.end(); }
} Note, the It seems, when one need to forward the request to another proxy, that proxy should still be specified in the "target" field. The "changeOrigin" should be set to "false". The "toProxy" option didn't make any difference in my experiments, but keeping it in "true" did not harm. The intention of the "forward" option is still very much unclear. |
2020.05.29 it's still unclear |
I believe the functionality of
It seems when the entire project was rewritten in #552, the functionality was preserved but the documentation went away. |
After reading the docs and examples, the purpose and distinction between
forward
andtarget
is still not clear to me (includingforward-and-target-proxy.js
example - I can't tell what this is actually demonstrating). After implementing a very simple single-steptarget
proxy behind Express, I wanted to place a transparent forward proxy in between Node and backend server in order to cache some large, expensive API requests. I was not successful with any permutation offorward
ortarget
options. My intuition was thattarget
would be used to "fix up" the outbound request (setupOutgoing
), whileforward
would be the immediate server to hand off to (the local caching proxy). It appears thatchangeOrigin
will use theforward
host, not thetarget
host. This is likely due to logic instream
andsetupOutgoing
that appears to modify the request for both cases. I'm not sure I understand the precedence of the piping. Alsoforward
will not convert a relative path request to an absolute URL request required by an upstream transparent HTTP proxy.It would be nice to have a some more docs on how to use
forward
andtarget
in combination or separately, and whether handoff to transparent proxy is supported out of the box (e.g. inference from combination offorward
andtarget
would be nice).I managed to manually perform these fixups when in 'transparent handoff' mode as advised on StackOverflow:
The text was updated successfully, but these errors were encountered: