Skip to content

router: remove upstream failure details from downstream body#44746

Merged
ggreenway merged 4 commits intoenvoyproxy:mainfrom
ggreenway:nobody
May 1, 2026
Merged

router: remove upstream failure details from downstream body#44746
ggreenway merged 4 commits intoenvoyproxy:mainfrom
ggreenway:nobody

Conversation

@ggreenway
Copy link
Copy Markdown
Member

When an upstream request fails, a local response is generated for the failure which previously included
%UPSTREAM_TRANSPORT_FAILURE_REASON%. This could include details such as invalid CAs or SAN mismatch, which are inappropriate to send to the client by default. This data is still included in all of uses of this substitution format string (access logs, traces, etc).

Fixes #44694

Additional Description:
Risk Level: Medium (behavior change)
Testing: Adjusted and added tests
Docs Changes: This behavior wasn't documented

When an upstream request fails, a local response is generated for the
failure which previously included
%UPSTREAM_TRANSPORT_FAILURE_REASON%. This could include details such
as invalid CAs or SAN mismatch, which are inappropriate to send to the
client by default. This data is still included in all of uses of this
substitution format string (access logs, traces, etc).

Fixes envoyproxy#44694

Signed-off-by: Greg Greenway <ggreenway@apple.com>
@repokitteh-read-only
Copy link
Copy Markdown

CC @envoyproxy/runtime-guard-changes: FYI only for changes made to (source/common/runtime/runtime_features.cc).

🐱

Caused by: #44746 was opened by ggreenway.

see: more, trace.

Signed-off-by: Greg Greenway <ggreenway@apple.com>
Copy link
Copy Markdown
Contributor

@prashanthjos prashanthjos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me

ravenblackx
ravenblackx previously approved these changes Apr 30, 2026
@ravenblackx
Copy link
Copy Markdown
Contributor

Looks like there's still some other tests being too sensitive.

Signed-off-by: Greg Greenway <ggreenway@apple.com>
Comment on lines +418 to 419
{":status", "503"}, {"content-length", "98"}, {"content-type", "text/plain"}};
EXPECT_CALL(callbacks_, encodeHeaders_(HeaderMapEqualRef(&response_headers), false));
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI for future things, you can implement this sort of thing in pure matchers something like

EXPECT_CALL(callbacks_, encodeHeaders_(AllOf(ContainsHeader(":status", "503"), ContainsHeader("content-type", "text/plain")), false));

And rather than validating content-length which is fragile and unreadable, could validate

EXPECT_CALL(callbacks_, encodeData(BufferStringContains("some substr of the body"), true));

(Which is also a bad matcher but I've already digressed.)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good to know! I agree these are really fragile right now.

@ggreenway ggreenway merged commit d9cd10d into envoyproxy:main May 1, 2026
29 checks passed
@zhaohuabing
Copy link
Copy Markdown
Member

Hi @ggreenway @wbpcode @phlax could we back port this to 1.8 ?

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.

Do not expose detailed TLS transport failure reasons in HTTP responses

4 participants