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

http: keep trailers TE header instead of removing it #32255

Merged
merged 23 commits into from Feb 12, 2024

Conversation

quantumsheep
Copy link
Contributor

@quantumsheep quantumsheep commented Feb 7, 2024

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

Copy link

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.

🐱

Caused by: #32255 was opened by quantumsheep.

see: more, trace.

Signed-off-by: Nathanael DEMACON <ndemacon@scaleway.com>
@@ -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);
Copy link
Contributor

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?

Copy link
Contributor Author

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?

@alyssawilk alyssawilk self-assigned this Feb 7, 2024
@alyssawilk
Copy link
Contributor

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.
Either way sorry the behavioral change was problematic for you all - I'm happy to work with you on a longer term solution
/wait

Signed-off-by: Nathanael DEMACON <ndemacon@scaleway.com>
if (Runtime::runtimeFeatureEnabled("envoy.reloadable_features.sanitize_te")) {
request_headers.removeTE();
if (Grpc::Common::isGrpcRequestHeaders(request_headers)) {
Copy link
Contributor

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

Copy link
Contributor

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.

Copy link
Contributor

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?

Copy link
Contributor Author

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

Copy link
Contributor

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?

Copy link
Contributor Author

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>
Signed-off-by: Nathanael DEMACON <ndemacon@scaleway.com>
Signed-off-by: Nathanael DEMACON <ndemacon@scaleway.com>
source/common/http/conn_manager_utility.cc Outdated Show resolved Hide resolved
source/common/http/conn_manager_utility.cc Outdated Show resolved Hide resolved
source/common/http/conn_manager_utility.cc Outdated Show resolved Hide resolved
source/common/http/conn_manager_utility.cc Outdated Show resolved Hide resolved
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>
@quantumsheep quantumsheep changed the title http: set TE header to trailers instead of removing it http: keep trailers TE header instead of removing it Feb 12, 2024
@alyssawilk alyssawilk removed their assignment Feb 12, 2024
@alyssawilk
Copy link
Contributor

I think it's fine given the documentation of the runtime guard change.

@RyanTheOptimist RyanTheOptimist merged commit 44fc421 into envoyproxy:main Feb 12, 2024
54 checks passed
@alyssawilk alyssawilk added the backport/review Request to backport to stable releases label Feb 26, 2024
ctvera pushed a commit to ctvera/envoy that referenced this pull request Mar 4, 2024
)

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>
@rajatvig
Copy link

rajatvig commented Mar 8, 2024

Could this be backported to the 1.29 release please? Dropping the TE header caused a lot of grief on our as GRPC Services relying on it being always present stopped working.

@oblazek
Copy link

oblazek commented Mar 8, 2024

Could this be backported to the 1.29 release please? Dropping the TE header caused a lot of grief on our as GRPC Services relying on it being always present stopped working.

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)

@RyanTheOptimist
Copy link
Contributor

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.

@rajatvig
Copy link

rajatvig commented Mar 8, 2024

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.

ctvera pushed a commit to ctvera/envoy that referenced this pull request Mar 15, 2024
)

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>
sunjayBhatia added a commit to sunjayBhatia/contour that referenced this pull request Mar 18, 2024
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>
sunjayBhatia added a commit to sunjayBhatia/contour that referenced this pull request Mar 18, 2024
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>
sunjayBhatia added a commit to sunjayBhatia/contour that referenced this pull request Mar 18, 2024
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>
sunjayBhatia added a commit to projectcontour/contour that referenced this pull request Mar 18, 2024
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>
sunjayBhatia added a commit to projectcontour/contour that referenced this pull request Mar 18, 2024
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>
phlax pushed a commit to phlax/envoy that referenced this pull request Mar 20, 2024
)

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>
htuch pushed a commit that referenced this pull request Mar 21, 2024
) (#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>
@phlax
Copy link
Member

phlax commented Apr 4, 2024

@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 phlax removed the backport/review Request to backport to stable releases label Apr 4, 2024
@quantumsheep
Copy link
Contributor Author

@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?)

@phlax
Copy link
Member

phlax commented Apr 4, 2024

optimistically today, realistically possibly tomorrow

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.

None yet

6 participants