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

gRPC: Add support to control envoy generated headers #34179

Merged
merged 15 commits into from
Jun 28, 2024

Conversation

tyxia
Copy link
Member

@tyxia tyxia commented May 15, 2024

This PR provides gRPC client level control over Envoy generated headers. It currently controls x-envoy-internal and x-forwarded-for (can be expanded if needed)

  • If true, header will be added. But it can be overridden by setting setSendInternal or setSendXff to false in
    Http::AsyncClient::StreamOptions, as per stream control.
  • If false, header will be removed and can not be overridden by per stream option.

This logic is designed in this way because:

  • Preserve backwards compatible behavior:
    • Both headers are still sent by default
    • If any existing users remove them with StreamOptions, headers are still removed
  • Still provide the per stream override control
  • The only thing is that now user can not set StreamOptions to true if they are disabled in config. But it should be fine because:
    • For existing user, no one should set them to true in StreamOptions as they are already default to true.
    • For future user, per stream control can still be achieved as stated above.

Copy link

As a reminder, PRs marked as draft will not be automatically assigned reviewers,
or be handled by maintainer-oncall triage.

Please mark your PR as ready when you want it to be reviewed!

🐱

Caused by: #34179 was opened by tyxia.

see: more, trace.

Copy link

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to (api/envoy/|docs/root/api-docs/).
envoyproxy/api-shepherds assignee is @lizan
CC @envoyproxy/api-watchers: FYI only for changes made to (api/envoy/|docs/root/api-docs/).

🐱

Caused by: #34179 was opened by tyxia.

see: more, trace.

tyxia added 2 commits May 15, 2024 12:48
Signed-off-by: Tianyu Xia <[email protected]>
Signed-off-by: Tianyu Xia <[email protected]>
@tyxia tyxia marked this pull request as ready for review May 15, 2024 23:26
@tyxia
Copy link
Member Author

tyxia commented May 15, 2024

/assign @htuch @lizan

PTAL, Thanks!

Signed-off-by: Tianyu Xia <[email protected]>
@jmarantz
Copy link
Contributor

/wait (for CI to be made green)

Signed-off-by: Tianyu Xia <[email protected]>
@tyxia tyxia marked this pull request as draft June 26, 2024 02:32
tyxia added 5 commits June 25, 2024 22:50
Signed-off-by: Tianyu Xia <[email protected]>
Signed-off-by: Tianyu Xia <[email protected]>
Signed-off-by: Tianyu Xia <[email protected]>
Signed-off-by: Tianyu Xia <[email protected]>
Signed-off-by: Tianyu Xia <[email protected]>
@tyxia tyxia changed the title gRPC API: Add support to control the internal request headers gRPC: Add support to control envoy generated headers Jun 26, 2024
@tyxia
Copy link
Member Author

tyxia commented Jun 26, 2024

/retest

Signed-off-by: Tianyu Xia <[email protected]>
@tyxia tyxia marked this pull request as ready for review June 26, 2024 20:25
@tyxia tyxia requested a review from htuch June 26, 2024 20:27
Signed-off-by: Tianyu Xia <[email protected]>
Signed-off-by: Tianyu Xia <[email protected]>
@tyxia
Copy link
Member Author

tyxia commented Jun 27, 2024

/retest

Copy link
Member

@htuch htuch 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!

@htuch htuch merged commit 9ce333b into envoyproxy:main Jun 28, 2024
52 of 53 checks passed
cainelli pushed a commit to cainelli/envoy that referenced this pull request Jul 5, 2024
This PR provides gRPC client level control over Envoy generated headers. It currently controls x-envoy-internal and x-forwarded-for (can be expanded if needed)

If false, header will be added. But it can be overridden by setting setSendInternal or setSendXff to false in
Http::AsyncClient::StreamOptions, as per stream control.
If true, header will be removed and can not be overridden by per stream option.
This logic is designed in this way because:

Preserve backwards compatible behavior:
Both headers are still sent by default
If any existing users remove them with StreamOptions, headers are still removed
Still provide the per stream override control
Override here implicitly means setting to false as their default value in AsyncClient::StreamOptions is true.
Thus, per stream override is still available, just in one-way direction: disable on per stream basis
The only thing is that now user can not set StreamOptions to true if they are disabled in config. But it should be fine because:
For existing user, no one should set them to true in StreamOptions as they are already default to true.
For future user, per stream control can still be achieved as stated above.

Signed-off-by: Tianyu Xia <[email protected]>
Signed-off-by: Fernando Cainelli <[email protected]>
cainelli pushed a commit to cainelli/envoy that referenced this pull request Jul 5, 2024
This PR provides gRPC client level control over Envoy generated headers. It currently controls x-envoy-internal and x-forwarded-for (can be expanded if needed)

If false, header will be added. But it can be overridden by setting setSendInternal or setSendXff to false in
Http::AsyncClient::StreamOptions, as per stream control.
If true, header will be removed and can not be overridden by per stream option.
This logic is designed in this way because:

Preserve backwards compatible behavior:
Both headers are still sent by default
If any existing users remove them with StreamOptions, headers are still removed
Still provide the per stream override control
Override here implicitly means setting to false as their default value in AsyncClient::StreamOptions is true.
Thus, per stream override is still available, just in one-way direction: disable on per stream basis
The only thing is that now user can not set StreamOptions to true if they are disabled in config. But it should be fine because:
For existing user, no one should set them to true in StreamOptions as they are already default to true.
For future user, per stream control can still be achieved as stated above.

Signed-off-by: Tianyu Xia <[email protected]>
Signed-off-by: Fernando Cainelli <[email protected]>
cainelli pushed a commit to cainelli/envoy that referenced this pull request Jul 5, 2024
This PR provides gRPC client level control over Envoy generated headers. It currently controls x-envoy-internal and x-forwarded-for (can be expanded if needed)

If false, header will be added. But it can be overridden by setting setSendInternal or setSendXff to false in
Http::AsyncClient::StreamOptions, as per stream control.
If true, header will be removed and can not be overridden by per stream option.
This logic is designed in this way because:

Preserve backwards compatible behavior:
Both headers are still sent by default
If any existing users remove them with StreamOptions, headers are still removed
Still provide the per stream override control
Override here implicitly means setting to false as their default value in AsyncClient::StreamOptions is true.
Thus, per stream override is still available, just in one-way direction: disable on per stream basis
The only thing is that now user can not set StreamOptions to true if they are disabled in config. But it should be fine because:
For existing user, no one should set them to true in StreamOptions as they are already default to true.
For future user, per stream control can still be achieved as stated above.

Signed-off-by: Tianyu Xia <[email protected]>
Signed-off-by: Fernando Cainelli <[email protected]>
cainelli pushed a commit to cainelli/envoy that referenced this pull request Jul 5, 2024
This PR provides gRPC client level control over Envoy generated headers. It currently controls x-envoy-internal and x-forwarded-for (can be expanded if needed)

If false, header will be added. But it can be overridden by setting setSendInternal or setSendXff to false in
Http::AsyncClient::StreamOptions, as per stream control.
If true, header will be removed and can not be overridden by per stream option.
This logic is designed in this way because:

Preserve backwards compatible behavior:
Both headers are still sent by default
If any existing users remove them with StreamOptions, headers are still removed
Still provide the per stream override control
Override here implicitly means setting to false as their default value in AsyncClient::StreamOptions is true.
Thus, per stream override is still available, just in one-way direction: disable on per stream basis
The only thing is that now user can not set StreamOptions to true if they are disabled in config. But it should be fine because:
For existing user, no one should set them to true in StreamOptions as they are already default to true.
For future user, per stream control can still be achieved as stated above.

Signed-off-by: Tianyu Xia <[email protected]>
Signed-off-by: Fernando Cainelli <[email protected]>
@tyxia tyxia deleted the ext_proc_disable branch August 27, 2024 20:19
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