You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This maps /something to / on the backend service. It works pretty well with nginx but the regular expression on the path breaks compatibility with other ingress controllers (e.g. traefik 1+2).
The expression part is required because it generates the following config:
rewrite "(?i)/something/(.*)" /$1 break;
Without the expression part, $1 is not available for rewrite.
Possible solutions:
Variant1: always add (.?) at the end of the 1st rewite parameter
Variant1a: add an annotation to enable Variant1
Variant1b: add (.?) at the end of the 1st rewite parameter if the 2nd parameter uses $1 but there's no capture group on the 1st parameter
Variant2: add an annotation that allows to override the 1st rewite parameter
Personally I see Variant1b as the best solution. It does not break any existing deployments and adds the requested feature without any additional annotations.
/kind feature
The text was updated successfully, but these errors were encountered:
@aledbf It seems that #555 was closed after the discussion lost focus. My proposal above would be an easy way to solve 90% of the portability issues with a minimal code change. Would you be open to talk about it?
I'd like to strip paths for forwarded URIs in a way that is compatible with other ingress controllers.
Example:
This maps /something to / on the backend service. It works pretty well with nginx but the regular expression on the path breaks compatibility with other ingress controllers (e.g. traefik 1+2).
The expression part is required because it generates the following config:
Without the expression part, $1 is not available for rewrite.
Possible solutions:
Variant1: always add (.?) at the end of the 1st rewite parameter
Variant1a: add an annotation to enable Variant1
Variant1b: add (.?) at the end of the 1st rewite parameter if the 2nd parameter uses $1 but there's no capture group on the 1st parameter
Variant2: add an annotation that allows to override the 1st rewite parameter
Personally I see Variant1b as the best solution. It does not break any existing deployments and adds the requested feature without any additional annotations.
/kind feature
The text was updated successfully, but these errors were encountered: