Skip to content
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

Merged
merged 4 commits into from
Feb 9, 2024

Conversation

liorokman
Copy link
Contributor

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 a headers container in the client traffic policy document.

@liorokman liorokman requested a review from a team as a code owner January 25, 2024 09:03
Copy link

codecov bot commented Jan 25, 2024

Codecov Report

Attention: 5 lines in your changes are missing coverage. Please review.

Comparison is base (f21f9ff) 63.94% compared to head (b771af6) 63.94%.
Report is 1 commits behind head on main.

Files Patch % Lines
...frastructure/kubernetes/proxy/resource_provider.go 50.00% 0 Missing and 4 partials ⚠️
internal/gatewayapi/clienttrafficpolicy.go 83.33% 1 Missing ⚠️
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.
📢 Have feedback on the report? Share it here.

)

// HeaderSettings providess configuration options for headers on the listener.
type HeaderSettings struct {
Copy link
Contributor

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

Copy link
Contributor Author

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

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 as passThrough 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.

Copy link
Contributor

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

Copy link
Contributor

@arkodg arkodg Feb 3, 2024

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

Copy link
Member

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.

Copy link
Contributor

@arkodg arkodg Feb 3, 2024

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fine to me

Copy link
Contributor Author

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:

  1. The HeaderSettings structure is removed, and the default behaviour becomes that the X-Envoy- headers are removed and the Server header is defined as passthrough. This is done to try to effectively hide the presence of an Envoy Proxy between the client and the upstream target.
  2. 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?

Copy link
Contributor

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
``

Copy link
Contributor Author

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.

@liorokman liorokman force-pushed the ctp-header-settings branch from 9ba81dd to e775ba9 Compare February 7, 2024 10:03
Headers *HeaderSettings `json:"headers,omitempty"`
}

// ServerHeaderTransformation specifies the transformation required for the Server header
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is not needed

Copy link
Contributor Author

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]>
Copy link
Contributor

@arkodg arkodg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM thanks !

@arkodg arkodg requested review from zirain and a team February 7, 2024 21:20
@shawnh2
Copy link
Contributor

shawnh2 commented Feb 9, 2024

/retest

@arkodg arkodg merged commit 53c9758 into envoyproxy:main Feb 9, 2024
19 of 20 checks passed
vixns pushed a commit to vixns/gateway that referenced this pull request Feb 18, 2024
* 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]>
@liorokman liorokman deleted the ctp-header-settings branch August 17, 2024 06:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants