-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Fix x-forwarded-prefix annotation #3786
Fix x-forwarded-prefix annotation #3786
Conversation
cf6e525
to
93b413b
Compare
@alexkursell can we use the new lint plugin feature to also provide examples of migration? |
@aledbf We can add a lint that warns on the use of x-forwarded-prefix with boolean values that links to this issue. Once the lint command is merged I'll add the lint to this PR. |
b7512e4
to
6cbfd4c
Compare
@aledbf I've added a lint for this change:
|
/approve |
/lgtm |
@alexkursell thanks! |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: aledbf, alexkursell, ElvinEfendi The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
if I have ingress with path as below (with re-write path
|
@Sudharma with this change the |
well but thats more hard-coded, Is it not possible to have it |
This is not possible right now. If you need a different header value for different backends you will need to create different ingresses. |
What this PR does / why we need it: With the now mandatory use of regexps in paths when using
rewrite-target
, thex-forwarded-prefix
annotation is broken.Before 0.22, setting the annotation to true would set the
x-forwarded-prefix
header value to the path value. However, now that the path always includes a capture group, doing this no longer makes sense.This PR changes the type of the
x-forwarded-prefix
annotation from bool to string, and changes things so that the value of thex-forwarded-prefix
header is just equal to the value of the annotation (if the annotation value exists and is non-empty).This is actually the behaviour that is explained by the docs (see here). My guess is that when this was changed to copying the path value into the header, the docs were never updated.
Which issue this PR fixes: fixes #3733, #3670, #3132
This would be a breaking change, so we should probably think about how migrating would work, as well as if there is a better way to do this.