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 suppressing the 'x-envoy-' headers added by the HTTP router #2358

Merged
merged 2 commits into from
Dec 26, 2023

Conversation

liorokman
Copy link
Contributor

What type of PR is this?
This PR enhances the ClientTrafficPolicy by adding the following option:

   # Suppress the "x-envoy-" headers from being added by the HTTP router.
   suppressEnvoyHeaders: true

What this PR does / why we need it:

This PR adds the ability to suppress the "x-envoy-" headers added by the Envoy HTTP router.

The following headers are affected:

Which issue(s) this PR fixes:
Support for this flag is mentioned in #1846

…uter.

Signed-off-by: Lior Okman <lior.okman@sap.com>
@liorokman liorokman requested a review from a team as a code owner December 25, 2023 09:14
Copy link

codecov bot commented Dec 25, 2023

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (243c42c) 64.80% compared to head (736f187) 64.73%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2358      +/-   ##
==========================================
- Coverage   64.80%   64.73%   -0.08%     
==========================================
  Files         113      113              
  Lines       16567    16567              
==========================================
- Hits        10737    10725      -12     
- Misses       5159     5168       +9     
- Partials      671      674       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Member

@zhaohuabing zhaohuabing left a comment

Choose a reason for hiding this comment

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

This will change both the downstream and upstream behavior. Would it be appropriate to put this in ClientTraffciPolicy?

@liorokman
Copy link
Contributor Author

The relevant Envoy Proxy configuration is this: https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/router/v3/router.proto#extensions-filters-http-router-v3-router .

It affects both upstream and downstream. It's not possible to affect just the upstream or just the downstream - Envoy Proxy doesn't give that option.

I think that both ClientTrafficPolicy and BackendTrafficPolicy are equally unfit, but that ClientTrafficPolicy is still the better fit. I think that users that look for something like this are looking for a way to prevent their downstream clients from receiving these headers.

Do you think there's a better place in the Envoy Gateway configuration to specify this?

@Xunzhuo
Copy link
Member

Xunzhuo commented Dec 26, 2023

/retest

@zhaohuabing
Copy link
Member

I think that both ClientTrafficPolicy and BackendTrafficPolicy are equally unfit, but that ClientTrafficPolicy is still the better fit. I think that users that look for something like this are looking for a way to prevent their downstream clients from receiving these headers.

Looks like this option only suppresses the headers generated by the router.

x-envoy-attempt-count
x-envoy-is-timeout-retry
x-envoy-expected-rq-timeout-ms
x-envoy-original-path
x-envoy-upstream-stream-duration-ms

And there are many more "x-envoy-xxx" headers generated by other filters, here is the full list: https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/headers

So I wonder whether this will work for the use case you mentioned or not.

Do you think there's a better place in the Envoy Gateway configuration to specify this?
Unfortunately, I don't have one either. EG doesn't have a home for such an option that affects both the downstream and upstream. I agree that we can settle with one of them.

@liorokman
Copy link
Contributor Author

So I wonder whether this will work for the use case you mentioned or not.

Looking at the list of headers mentioned in the HTTP connection manager documentation:

  • x-envoy-downstream-service-cluster is only added if the add_user_agent option is set to true
  • x-envoy-downstream-service-node is only added if the add_user_agent is set to true
  • x-envoy-force-trace is relevant if it's already set in the incoming request
  • x-envoy-internal was only sent upstream in my tests, and removed from the response, so no issues here.
  • x-envoy-original-dst-host needs to be enabled explicitly with the use_http_header configuration.

This only leaves the x-envoy-external-address header.

Copy link
Member

@zhaohuabing zhaohuabing left a comment

Choose a reason for hiding this comment

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

LGTM. Defer to other @envoyproxy/gateway-maintainers

Copy link
Contributor

@zirain zirain left a comment

Choose a reason for hiding this comment

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

LGTM

@liorokman
Copy link
Contributor Author

@zirain @zhaohuabing Can I submit a PR that implements this?

@zirain
Copy link
Contributor

zirain commented Dec 26, 2023

This's a small changes, you can do the implement here, or you can send another one later.

@zirain zirain merged commit bda0055 into envoyproxy:main Dec 26, 2023
18 checks passed
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