-
Notifications
You must be signed in to change notification settings - Fork 584
Extend VS.HTTPRoute with RegexRewrite #1566
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
Conversation
|
/test build_api |
| oneof rewrites { | ||
| // Rewrite HTTP URIs and Authority headers. Rewrite cannot be used with | ||
| // Redirect primitive. Rewrite will be performed before forwarding. | ||
| HTTPRewrite rewrite = 4; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rewrite:
authority:
uri:
regexRewrite:
regex:
Seems like these are the possible options, which raises the question to me - what is being rewritten by regex, the uri or the authority? And can I do a authority prefix rewrite along with a regex rewrite of uri?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is clear to users or consistent with the existing field. we should either change regex to uri or nest it under rewrite maybe?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see.. So I can nest rewriteRegex under rewrite. Will do that change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@howardjohn given that we can either have rewrite or regexRewrite have it nested under rewrite doesn't make sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I am not sure why it doesn't make sense?
rewrite:
authority:
uri:
regexRewrite:
regex:
is clearly inconsistent to me.
rewrite:
authority:
uri:
regix: ...
prefix: ...
is ideal. However, it is not backwards compatible.
Therefor it seems that:
rewrite:
authority:
uri: ...prefix...
uriRegix: ...regex..
is the most consistent
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@howardjohn yes.. makes sense. fixed in latest changes.
|
@abhide can you add examples in the doc on how to use regex rewrite? This is a great functionality to add but will be difficult for users to follow without concrete examples. |
@nrjpoddar Do you want me to add envoy regex examples? Essentially, we would be passing the values from VS to envoy config, correct? |
Yes please. An example of a simple regex (we don't need a complex one, we want to show how it can be used not how regex works), and the input URL and what it will be rewritten to. |
Tickets: GH-22290
|
@howardjohn @nrjpoddar Added a WIP patch that uses these API changes: istio/istio#28098 Looking for feedback/comments so that we can work through naming params and documentation. |
| UriRegexRewrite uri_regex = 3; | ||
| } | ||
|
|
||
| message UriRegexRewrite { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using same parameter names as envoy: https://www.envoyproxy.io/docs/envoy/latest/api-v2/api/v2/route/route_components.proto#envoy-api-field-route-routeaction-regex-rewrite
| string authority = 2; | ||
|
|
||
| // uri_regex can be used for rewriting portions of path that match the | ||
| // pattern during forwarding the request |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| // pattern during forwarding the request | |
| // pattern when forwarding the request. |
| string authority = 2; | ||
|
|
||
| // uri_regex can be used for rewriting portions of path that match the | ||
| // pattern during forwarding the request |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| // pattern during forwarding the request | |
| // pattern when forwarding the request. |
|
Hi istio team, I've been following this issue and PR since september past year, we want to migrate to istio but we need regex rewrite rules to replace nginx-ingress. Is there any chance this PR could be merged soon? Thank you in advance. |
|
I am a bit concerned with this - can you add a discussion on networking WG ? I don't think Istio API must mirror all the features in envoy - right now the consensus in the WG is to adopt the upstream I don't think RE2 based rewrite a URL is a common enough feature that would be supported cross-vendor, and it puts |
|
At least we should bounce the idea with the K8S Services WG - and the other projects planning to support the K8S APIs. |
|
I am not actively working on this GH issue. Will un-assign myself so that someone can pick it up. |
|
I really need this awesome feature and want to support it. Can I pick it up? @howardjohn @hzxuzhonghu |
@costinm I'm not sure how you can say that routing/rewriting with path variables is "unreasonable" "advanced" "uncommon" Have you never written a API that's like this: |
|
@SpecialYang have you build a forked image for this? |
Tickets: GH-22290