-
Notifications
You must be signed in to change notification settings - Fork 90
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
Support rewrote targets during path based routing #851
Comments
@tomkerkhove @t0rr3sp3dr0 , WDYT about this feature? |
I have the same concern. My case is slightly different as I am using Kong API Gateway. However, when it comes to path-based routing in the interceptor level, I ended up with the same technical issue. If possible, could we have a feature like “strip-path: true”? |
Ingress-nginx provides a configuration property called |
I like the idea of supporting X-Original-URI but I think that it's not an standard and it can be a problem in the future :/ |
I think we need to define the scope of the add-on first. I'm not sure if we just want to provide a solid base for HTTP scaling or if we want to have feature-parity with generic ingresses. I would prioritize other features before implementing this, given it's something that can be achieved with the current implementation by adding Nginx or other kind of proxy between the add-on and the service. |
No no, I didn't mean to apply the rewrite in the add-on. As you said, this can be done by load balancer. My point is that if you have a load balancer on top which replaces the path during the process, in the add-on we won't know the correct route.
If the ingresses apply a redirect to / during the process, each backend will receive the request on /, which is correct. The problem is that the add-on will receive it also for /, and here the add-on doesn't work as HTTPScaledObjects are configured to route paths |
My suggestion was not to have something rewriting paths at the Ingress/LoadBalancer level. As you just explained, that wouldn’t work because we would loose access to the full paths in the add-on. What I was suggesting was to make the add-on point to Nginx, HAProxy, or anything that is able to manipulate HTTP. In the HTTPSO spec, the service field would be the name of the service that points to the proxy. And the proxy would be the one responsible for rewriting paths and forwarding them to the service we are scaling. I know this is an extra thing that developers would need to setup and manage, but at the same time our current scope doesn’t include rewriting paths: https://github.com/kedacore/http-add-on/blob/main/docs/scope.md. And I’m not saying we shouldn’t support this kind of feature, just that it would be wise to discuss it before taking this path. Would we like to support other stuff that is currently achievable with a proxy? Here are some examples of HTTP manipulations we could potentially support: https://www.haproxy.com/documentation/haproxy-configuration-tutorials/http-rewrites/. If we don’t want support everything, what’s is our boundary and why? |
I fully agree with your point. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions. |
is there any news about this one? Does someone have any workaround to share? The project itself is quite great, but unfortunately, this issue is blocking us from implementing it 🙁 |
Hi, My main use case for the scaler is the deployment from zero to reduce the overall co2 foodprint of my applications. Adding another proxy is working in a different direction. One more argument against the proxy that might only be relevant for some people. |
Proposal
Reverse proxies support rewriting the path before calling the next backend.
Imagine this ingress:
Requests to the interceptor won't contain the full path but the rewrote path, for example
https://potato.com/store/checkout
will be passed to the interceptor ashttps://potato.com/checkout
.The problem is that if we want to support path based routing in the interceptor, we need to maintain the pathPrefix. For example, this HTTPScaledObject doesn't work:
This won't work due to this removed prefix, and the same request (https://potato.com/store/checkout) returns 404 and generates an error like this the interceptor:
TBH, I'm not sure about the best approach here. Maybe we can introduce a custom header (via snippet) in the ingress with the original path (IDK if this is possible), or even better (but more complicated and worse for migration to the add-on), supporting the target-rewrite at interceptor level.
This second option (supporting the rewrites within interceptor) allows users to maintain their current backends without any change as in that scenario, they would have to move the rewrite from ingress to interceptor and backends would continue without any change.
The text was updated successfully, but these errors were encountered: