-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
http: keep trailers
TE header instead of removing it
#32255
http: keep trailers
TE header instead of removing it
#32255
Conversation
Hi @quantumsheep, welcome and thank you for your contribution. We will try to review your Pull Request as quickly as possible. In the meantime, please take a look at the contribution guidelines if you have not done so already. |
Signed-off-by: Nathanael DEMACON <ndemacon@scaleway.com>
4cc114a
to
2611451
Compare
@@ -93,7 +93,7 @@ ConnectionManagerUtility::MutateRequestHeadersResult ConnectionManagerUtility::m | |||
request_headers.removeConnection(); | |||
request_headers.removeUpgrade(); | |||
if (Runtime::runtimeFeatureEnabled("envoy.reloadable_features.sanitize_te")) { | |||
request_headers.removeTE(); | |||
request_headers.setTE(Http::Headers::get().TEValues.Trailers); |
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.
I don't think this is correct either. TE may not have been "trailers" to begin with. Maybe check to see if there's a trailers token and if so replace any non'trailers string with trailers?
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.
HTTP/2 and 3 only supports trailers
TE headers in theory. I added a condition to do this only if the outgoing request is in gRPC, wdyt?
Also beyond that, I don't think preserving trailers across hops is the correct thing by the spec. I think if you want trailers on the upstream hop you should configure Envoy to send them upstream. |
Signed-off-by: Nathanael DEMACON <ndemacon@scaleway.com>
2ff7fb0
to
cfe8dd4
Compare
if (Runtime::runtimeFeatureEnabled("envoy.reloadable_features.sanitize_te")) { | ||
request_headers.removeTE(); | ||
if (Grpc::Common::isGrpcRequestHeaders(request_headers)) { |
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.
I think TE is a hop by hop header, and if we want to send it upstream we should configure it in request_headers_to_add. For example if someone has a web gRPC filter and is downgrading from HTTP/2 gRPC to HTTP/1.1 they wouldn't necessarily support trailers on the upstream to envoy hop.
cc @RyanTheOptimist for thoughts
/wait
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.
Yeah, I agree with @alyssawilk. It seems like request_headers_to_add would be a more standards complaint solution.
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.
After catching up on #30535, I think I've changed my mind. I think that Envoy should send "TE: trailers" to the upstream when the downstream client sent it to Envoy. So instead of adding adding "trailers" when it's a gRPC request, I wonder if we should change the TE sanitization logic to preserve trailers, if present?
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.
@alyssawilk we could remove the TE header when making an HTTP/1 request and keep it as trailers
when doing an HTTP/2 or 3 request.
@RyanTheOptimist I like this idea, I updated the MR
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.
It sounds like we're converging, which is great. it looks like the current patch set preserves trailers, if it was present. Since the TE header can have multiple values, do we need to check that trailers is one of the values in the list as opposed to just checking the string value of the field?
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.
You're right! It's updated.
Signed-off-by: Nathanael DEMACON <ndemacon@scaleway.com>
13c24b2
to
afc5512
Compare
Signed-off-by: Nathanael DEMACON <ndemacon@scaleway.com>
Signed-off-by: Nathanael DEMACON <ndemacon@scaleway.com>
Signed-off-by: Nathanael DEMACON <ndemacon@scaleway.com>
Signed-off-by: Nathanael DEMACON <ndemacon@scaleway.com>
Signed-off-by: Nathanael DEMACON <ndemacon@scaleway.com>
Signed-off-by: Nathanael DEMACON <ndemacon@scaleway.com>
Signed-off-by: Nathanael DEMACON <ndemacon@scaleway.com>
Signed-off-by: Nathanael DEMACON <ndemacon@scaleway.com>
Signed-off-by: Nathanael DEMACON <ndemacon@scaleway.com>
Signed-off-by: Nathanael DEMACON <ndemacon@scaleway.com>
Signed-off-by: Nathanael DEMACON <ndemacon@scaleway.com>
Signed-off-by: Nathanael DEMACON <ndemacon@scaleway.com>
I think it's fine given the documentation of the runtime guard change. |
) Official grpc library does not allow empty TE header. This causes an issue when proxying requests through Envoy which currently deletes the TE header since envoyproxy#30535. I opened a related MR on the grpc library to allow this header to be empty as the HTTP/2 RFC allows it but it might cause issues with other libraries. Risk Level: medium (behavioral change) Testing: modified an existing test Docs Changes: n/a Release Notes: inline Platform Specific Features: Runtime guard: keep the previous one Signed-off-by: Nathanael DEMACON <ndemacon@scaleway.com>
Could this be backported to the 1.29 release please? Dropping the |
I heavily agree with that.. this has caused a lot of troubles for us as well and had to cherry-pick this into 1.29 (or rollback to 1.28.1) |
That's certainly an option. But in the meantime you can just set envoy.reloadable_features.sanitize_te to false in order to get the previous behavior. |
Yes, that would work but we use Envoy with the xDS implementation of Contour in Kubernetes and that limits our ability to set arbitrary runtime features without putting in workarounds in the bootstrapping process. |
) Official grpc library does not allow empty TE header. This causes an issue when proxying requests through Envoy which currently deletes the TE header since envoyproxy#30535. I opened a related MR on the grpc library to allow this header to be empty as the HTTP/2 RFC allows it but it might cause issues with other libraries. Risk Level: medium (behavioral change) Testing: modified an existing test Docs Changes: n/a Release Notes: inline Platform Specific Features: Runtime guard: keep the previous one Signed-off-by: Nathanael DEMACON <ndemacon@scaleway.com>
Removal of the header was added by default in Envoy v1.29.0. This change reverts back to prior behavior. This change can be reverted once envoyproxy/envoy#32255 is backported or present in a new release of Envoy. Signed-off-by: Sunjay Bhatia <sunjayb@vmware.com>
Removal of the header was added by default in Envoy v1.29.0. This change reverts back to prior behavior. This change can be reverted once envoyproxy/envoy#32255 is backported or present in a new release of Envoy. Signed-off-by: Sunjay Bhatia <sunjayb@vmware.com>
Removal of the header was added by default in Envoy v1.29.0. This change reverts back to prior behavior. This change can be reverted once envoyproxy/envoy#32255 is backported or present in a new release of Envoy. Signed-off-by: Sunjay Bhatia <sunjayb@vmware.com>
Removal of the header was added by default in Envoy v1.29.0. This change reverts back to prior behavior. This change can be reverted once envoyproxy/envoy#32255 is backported or present in a new release of Envoy. Signed-off-by: Sunjay Bhatia <sunjayb@vmware.com>
Removal of the header was added by default in Envoy v1.29.0. This change reverts back to prior behavior. This change can be reverted once envoyproxy/envoy#32255 is backported or present in a new release of Envoy. Signed-off-by: Sunjay Bhatia <sunjayb@vmware.com>
) Official grpc library does not allow empty TE header. This causes an issue when proxying requests through Envoy which currently deletes the TE header since envoyproxy#30535. I opened a related MR on the grpc library to allow this header to be empty as the HTTP/2 RFC allows it but it might cause issues with other libraries. Risk Level: medium (behavioral change) Testing: modified an existing test Docs Changes: n/a Release Notes: inline Platform Specific Features: Runtime guard: keep the previous one Signed-off-by: Nathanael DEMACON <ndemacon@scaleway.com> Signed-off-by: Ryan Northey <ryan@synca.io>
) (#33018) Official grpc library does not allow empty TE header. This causes an issue when proxying requests through Envoy which currently deletes the TE header since #30535. I opened a related MR on the grpc library to allow this header to be empty as the HTTP/2 RFC allows it but it might cause issues with other libraries. Risk Level: medium (behavioral change) Testing: modified an existing test Docs Changes: n/a Release Notes: inline Platform Specific Features: Runtime guard: keep the previous one Signed-off-by: Nathanael DEMACON <ndemacon@scaleway.com> Signed-off-by: Ryan Northey <ryan@synca.io> Co-authored-by: Nathanael Demacon <nathanael.dmc@outlook.fr>
@quantumsheep @sunjayBhatia @jbohanon this has been backported to the 1.29 branch and will imminently get a release im not clear if this should be backported further but will remove the backport/review tag for now - lmk if it does need further backporting |
@phlax the issue was only present in 1.29, it's perfect! Do you know when the release will arrive ? (today or in the coming days?) |
optimistically today, realistically possibly tomorrow |
Official grpc library does not allow empty TE header. This causes an issue when proxying requests through Envoy which currently deletes the TE header since #30535.
I opened a related MR on the grpc library to allow this header to be empty as the HTTP/2 RFC allows it but it might cause issues with other libraries.
Risk Level: medium (behavioral change)
Testing: modified an existing test
Docs Changes: n/a
Release Notes: inline
Platform Specific Features:
Runtime guard: keep the previous one