-
Notifications
You must be signed in to change notification settings - Fork 365
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
api: Support Server header transformations #2500
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #2500 +/- ##
=======================================
Coverage 63.94% 63.94%
=======================================
Files 117 117
Lines 18057 18062 +5
=======================================
+ Hits 11546 11550 +4
- Misses 5758 5761 +3
+ Partials 753 751 -2 ☔ View full report in Codecov by Sentry. |
) | ||
|
||
// HeaderSettings providess configuration options for headers on the listener. | ||
type HeaderSettings struct { |
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.
we discussed this in the community meeting today, here are some follow up questions
- can this use case we solved with the ResponseHeaderFilter ?
https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.HTTPHeaderFilter - can the
suppressEnvoyHeaders
be represented with another name closer to the goal of the field such aspassThrough
etc ?
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.
we discussed this in the community meeting today, here are some follow up questions
- can this use case we solved with the ResponseHeaderFilter ?
https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.HTTPHeaderFilter
No. The ResponseHeaderFilter
unconditionally adds/overwrites a header whose value is given in the filter. This feature's passThrough
option will keep the value of the Server header provided by the upstream, and there's no way to express the appendIfAbsent
option with ResponseHeaderFilter
.
- can the
suppressEnvoyHeaders
be represented with another name closer to the goal of the field such aspassThrough
etc ?
You meant serverHeaderTransformation
, not suppressEnvoyHeaders
, right? suppressEnvoyHeaders
has nothing to do with passing anything through and isn't the topic of this PR.
I used the name of the underlying feature in Envoy Proxy for the serverHeaderTransformation
field. I think passThrough
isn't a good name - it's only one of three options, and is exactly the opposite of the overwrite
option.
I'm open to any other name you have that you think fits better.
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.
from a user perspective, (correct me if im wrong), what you're really trying to solve here is - hey envoy, dont add any new response headers like x-envoy-*
or server
we should come up with a name for this knob to define this opt in behavior
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.
how about a knob called addEnvoyResponseHeaders
, making adding envoy headers along with server
as opt in, so we supress by default
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.
maybe istio/api#2240 will give a little help.
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.
thanks for sharing this @zirain, this is super useful
how about removing this API and disabling
- x-envoy-*
- server (passthrough)
by default
and we can introduce APIs in the future to opt into this
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.
fine to me
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.
So, to summarise the above:
- The
HeaderSettings
structure is removed, and the default behaviour becomes that theX-Envoy-
headers are removed and the Server header is defined aspassthrough
. This is done to try to effectively hide the presence of an Envoy Proxy between the client and the upstream target. - There is no support at this time for allowing the
X-Envoy
headers. This makes it harder for developers to perform certain tasks, for example when trying to measure latency with the x-envoy-upstream-service-time, or debugging various rewrite rules with the x-envoy-original-path header.
How to proceed? Should I close this PR and create a new PR removing the suppressEnvoyHeaders
option and implementing the behavioural changes listed here?
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.
hey @liorokman, agree with 1.
for 2. we can make a opt in API e.g.
headers:
enableEnvoyHeaders: true
``
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.
Updated to reflect this thread.
This PR changes the API and keeps the project building, a different PR will actually implement the feature.
Signed-off-by: Lior Okman <[email protected]>
Signed-off-by: Lior Okman <[email protected]>
Signed-off-by: Lior Okman <[email protected]>
9ba81dd
to
e775ba9
Compare
Headers *HeaderSettings `json:"headers,omitempty"` | ||
} | ||
|
||
// ServerHeaderTransformation specifies the transformation required for the Server header |
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.
this is not needed
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.
Missed that. Removed.
Signed-off-by: Lior Okman <[email protected]>
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.
LGTM thanks !
/retest |
* Also updates the API to make adding x-envoy-* headers as opt in, rather than opt out Signed-off-by: Lior Okman <[email protected]> Signed-off-by: Stéphane Cottin <[email protected]>
What this PR does / why we need it:
This PR adds support for defining what should be done with the Server header.
The relevant Envoy configuration is here.
This PR additionally moves the
SuppressEnvoyHeaders
attribute into aheaders
container in the client traffic policy document.