-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Conversation
Signed-off-by: Tianyu Xia <[email protected]>
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
Signed-off-by: Tianyu Xia <[email protected]>
Signed-off-by: Tianyu Xia <[email protected]>
Signed-off-by: Tianyu Xia <[email protected]>
/wait (for CI to be made green) |
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]>
Signed-off-by: Tianyu Xia <[email protected]>
…roc_disable Signed-off-by: Tianyu Xia <[email protected]>
Signed-off-by: Tianyu Xia <[email protected]>
/retest |
Signed-off-by: Tianyu Xia <[email protected]>
Signed-off-by: Tianyu Xia <[email protected]>
Signed-off-by: Tianyu Xia <[email protected]>
/retest |
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!
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]>
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]>
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]>
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]>
This PR provides gRPC client level control over Envoy generated headers. It currently controls
x-envoy-internal
andx-forwarded-for
(can be expanded if needed)setSendInternal
orsetSendXff
to false inHttp::AsyncClient::StreamOptions
, as per stream control.This logic is designed in this way because:
StreamOptions
, headers are still removedsetting to false
as their default value inAsyncClient::StreamOptions
is true.StreamOptions
to true if they are disabled in config. But it should be fine because:StreamOptions
as they are already default to true.