-
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
"nginx.org/rewrites" requires a very strict format; can it be relaxed? #388
Comments
@ronchalant thanks for report. I've created a PR #389 that improves parsing of the rewrites annotation. Now the whitespace is handled better.
that's definitely more usable then a single string. Thanks for the example. Regarding Btw, right now there is a way to split one Ingress resource into multiple with mergeable Ingress resources. If some annotation cannot be applied per service, you can still use that annotation on per service basic if you split the Ingress into multiple Ingresses. |
thanks @pleshakov - I'll take a look at the mergeable Ingress resources. |
the PR with a fix #389 was merged. The fix is available in the edge version -- https://github.com/nginxinc/kubernetes-ingress/#nginx-ingress-controller-releases |
Closing, this fix is now available in the latest stable release |
Is your feature request related to a problem? Please describe.
nginx.org/rewrites
rules formatting is very strict - you cannot have a whitespace before theserviceName
when multiple rules are entered.For example if it's defined this way:
"serviceName=a rewrite=/a; serviceName=b rewrite=/b;serviceName=c rewrite=/c"
Then a and c are picked up, but because the b rule has a leading space it doesn't get picked up.
Describe the solution you'd like
It would be good to have this strict-formatting relaxed a bit, supporting the existing semicolon-separated strings with better handling of whitespaces, but also perhaps other native-YAML array formats.
Some samples/suggestions below:
Multiline string
if the existing rule definitions were maintained but whitespaces were better handled the above would be usable
As YAML array of objects
Describe alternatives you've considered
It works as-is if you remove white-spaces, but if you have many rules it becomes harder to read/manager.
The text was updated successfully, but these errors were encountered: