Maintenance #1251
Maintenance #1251
Conversation
Add method parameter to options for overriding the proxy-outgoing HTTP-method
README.md
Outdated
| * `false` (default): disable cookie rewriting | ||
| * String: new path, for example `cookiePathRewrite: "/newPath/"`. To remove the path, use `cookiePathRewrite: ""`. To set path to root use `cookiePathRewrite: "/"`. | ||
| * Object: mapping of paths to new paths, use `"*"` to match all paths. | ||
| For example keep one path unchanged, rewrite one path and remove other paths: |
There was a problem hiding this comment.
Minor nit: keep -> to keep
README.md
Outdated
| * **proxyTimeout**: timeout (in millis) for outgoing proxy requests | ||
| * **timeout**: timeout (in millis) for incoming requests | ||
| * **followRedirects**: true/false, Default: false - specify whether you want to follow redirects | ||
| * **selfHandleRequest** true/false, if set to true, none of the webOutgoing passes are called and its your responsibility ro appropriately return the response by listening and acting on the `proxyRes` event |
README.md
Outdated
| @@ -442,6 +486,33 @@ proxy.close(); | |||
|
|
|||
| ### Miscellaneous | |||
|
|
|||
| If you want to handle your own response after receiving the proxyRes, you can do | |||
| so with `selfHandleResponse` | |||
There was a problem hiding this comment.
A bit more clarification would be helpful here:
Not sure what it means to handle my own response. Does this mean that I will return my own response to the proxy client? Does the response have to be a modified version of the target webpage response?
A more descriptive var name would also be helpful (e.g., returnCustomResponse).
There was a problem hiding this comment.
or is selfHandleRequest is the options above the same as selfHandleResponse?
There was a problem hiding this comment.
@donasaur yea good catch it is supposed to just be selfHandleResponse in general. The feature is basically you are taking responsibility for returning whatever you want to the original response after the proxyRequest happens and returns its response. This was the name given by the contributor I'm ok with finding something that makes more sense. Its just trying to indicate that its your responsibility to return the response if thats something you needed to do. modifyResponse is also another idea.
When the server do not accept the upgrade request for websockets the server's response was previously not included and sent back. Now the proxy will include the response in these cases. Fixes #890.
This PR tries to fix "Can't set headers after they are sent" errors. That are a lot of situations where this error can occurs. In my case, it is happening because I have others middlewares (in an expressjs application that tries to proxy requests). Some of those middlewares (like [passportjs](http://passportjs.org/), or [cors](https://www.npmjs.com/package/cors)) can run ```res.end()``` and when the proxy receive a response, it is already finished. So, it is necessary to test if we can write on the user response when the proxy response is ready. I think it could also fix #930, #1168, #908
object.keys in web-incoming.js results in a non-deterministic ordering of keys, which means that in web-outgoing writeHead might be called before setHeader, which throws an error
…lfHandleRequest is the only way that functionality works
|
@Tigge removed that line from the commit. Again, thanks for the contribution! |
Running branch for merging PRs into that will properly run tests and pins dependencies as it should be.