-
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: clear hop by hop TE header #30535
Conversation
4ff13c1
to
5958a8e
Compare
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
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.
Looks great!
@@ -1375,8 +1377,9 @@ TEST_P(HeaderIntegrationTest, TestTeHeaderPassthrough) { | |||
}); | |||
} | |||
|
|||
// Validates TE header is stripped if it contains an unsupported value | |||
// Validates TE header was stripped if it contains an unsupported value |
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.
nit: Your call, but I'd be inclined to use the present tense here as it's describing what the test is going to do, not what it has done. But totally your call.
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.
sure
@@ -1341,8 +1341,10 @@ TEST_P(HeaderIntegrationTest, PathWithEscapedSlashesRedirected) { | |||
}); | |||
} | |||
|
|||
// Validates TE header is forwarded if it contains a supported value | |||
// Validates TE header was forwarded if it contains a supported value | |||
// It is now treated as the hop by hop header it is. |
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.
Should we remove this comment? I'm not sure that I understand why it's here?
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.
done
- area: http | ||
change: | | ||
Sanitize the hop by hop TE header from downstream request headers. This change can be temporarily reverted | ||
by setting ``envoy.reloadable_features.sanitize_te`` to false. |
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.
Does this flag sanitize the TE header, or does it remove it?
default_request_headers_.setTE("gzip"); | ||
} else { | ||
return; | ||
} |
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.
nit: Early return:
if (downstreamProtocol() != Http::CodecType::HTTP1) {
return;
}
default_request_headers_.setTE("gzip");
Optionally put this early return at the top of the test to make it clear that it's H1-specific.
Since Envoy 1.29 I get Removing the TE isn't the solution. We should replace it by |
So thankfully this is runtime guarded so you should be able to reinstate prior behavior with a config change. I think if you want the envoy-upstream hop to support trailers you should just add request headers "te: trailers" to the outgoing request. |
If you are meaning unconditionally, that seems a bit simplistic. That ignores whether the originating client supports trailers. From RFC 7230 §4.1.2:
"any downstream clients" being the important part. So you'd want to make it conditional based on the originating request. |
Oh, interesting. Yes, I think that's a good point. Envoy itself is able to process trailers and pass them along, but it's only "safe" to do that in the case where Envoy knows that the downstream client is able to process trailers. The client, of course, indicates this by sending "trailers" in te. Does that sound right? |
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>
) 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>
) 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>
) 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>
Changes Envoy to clear TE header by default, as it is a hop by hop header and should not be forwarded on.
Risk Level: medium (behavioral change)
Testing: new e2e test
Docs Changes: n/a
Release Notes: inline.
[Optional Runtime guard:] yes.
Fixes #30362