gRPC: Add support to control envoy generated headers #34179
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Tianyu Xia <tyxia@google.com>
|
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
Signed-off-by: Tianyu Xia <tyxia@google.com>
htuch
reviewed
May 17, 2024
Signed-off-by: Tianyu Xia <tyxia@google.com>
|
/wait (for CI to be made green) |
Signed-off-by: Tianyu Xia <tyxia@google.com>
Signed-off-by: Tianyu Xia <tyxia@google.com>
Signed-off-by: Tianyu Xia <tyxia@google.com>
Signed-off-by: Tianyu Xia <tyxia@google.com>
tyxia
changed the title
…roc_disable Signed-off-by: Tianyu Xia <tyxia@google.com>
|
/retest |
htuch
reviewed
Jun 27, 2024
htuch
reviewed
Jun 27, 2024
Signed-off-by: Tianyu Xia <tyxia@google.com>
|
/retest |
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 <tyxia@google.com> Signed-off-by: Fernando Cainelli <fernando.cainelli-external@getyourguide.com>
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 <tyxia@google.com> Signed-off-by: Fernando Cainelli <fernando.cainelli-external@getyourguide.com>
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 <tyxia@google.com> Signed-off-by: Fernando Cainelli <fernando.cainelli-external@getyourguide.com>
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 <tyxia@google.com> Signed-off-by: Fernando Cainelli <fernando.cainelli-external@getyourguide.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR provides gRPC client level control over Envoy generated headers. It currently controls
x-envoy-internalandx-forwarded-for(can be expanded if needed)setSendInternalorsetSendXffto false inHttp::AsyncClient::StreamOptions, as per stream control.This logic is designed in this way because:
StreamOptions, headers are still removedsetting to falseas their default value inAsyncClient::StreamOptionsis true.StreamOptionsto true if they are disabled in config. But it should be fine because:StreamOptionsas they are already default to true.