Do not terminate request after proxy response. Add option to pass proxyResponse to next middleware

[hpl002]

A feature that is missing from most proxy middleware that i have seen, and it is driving me crazy.

Response is currently terminated after proxy. I simply want to pass it along the good ol middleware stack and end the response later down the road.

Story

Validate incoming request against schema, proxy request, and then validate proxy response. If response if OK, then return proxy response to client, if not then return validation errors.

---

skipToNextHandlerFilter is a breath of fresh air after pulling my hair out with http-proxy-middleware. They have no fall-through option and i know for certain that this is something the users want.

skipToNextHandlerFilter does give me the ability to call my next middleware, but does not give me the option to return the proxy response in the event that the response is valid.

Allows you to inspect the proxy response, and decide if you want to continue processing (via express-http-proxy) or call next() to return control to express.

Can this be extended such that the proxyResponse is returned in next?

---

Kudos on a very well designed module and community involvement. Glad to see that issues are being answered and addressed.

Best

Herman

[monkpow]

Interesting. Thanks for the well written report. Let me look into this for a bit and I'll update you.

[sudharsans85]

+1. Any update on this? Able to relate myself to Herman - have been trying to locate a proxy middleware that allows fallthrough and pretty much no luck so far. This is the closest one - Was this taken up?

[bas080]

@sudharsans85, It requires a very small code change to enable fall-through to next middleware. I think however that this issue also does not want to end the connection so that further sending can be performed.

Should there be a separate issue for the fall-through feature?

[aemb87]

Hi! any update on this?

Ive been able todo some things with res.expressHttpProxy as indicated in this closed issue #361 but it seems a bit obscure.