reverse tunnel: read handshake headers from the live extension#46382
Open
kanurag94 wants to merge 7 commits into
Open
reverse tunnel: read handshake headers from the live extension#46382kanurag94 wants to merge 7 commits into
kanurag94 wants to merge 7 commits into
Conversation
The reverse-connection listen socket snapshots the handshake formatters when it's created, and that can happen before onServerInitialized() has built them. The snapshot ends up null and gets reused for every re-dial, so handshake additional_headers that use a formatter (%FILE_CONTENT%, SDS-backed secrets, etc.) went out as the raw template string instead of the resolved value. Read the formatters straight from the extension when we assemble the handshake instead of trusting that snapshot, falling back to the snapshot only when the extension hasn't built any. This is a follow-up to envoyproxy#46168, which fixed the same symptom in the extension constructor but missed the socket() -> io_handle -> wrapper snapshot path. Adds a regression test that goes through the real socket() path so it can't regress. Signed-off-by: Anurag Aggarwal <kanurag94@gmail.com>
kanurag94
force-pushed
the
fix-reverse-tunnel-handshake-live-headers
branch
from
July 25, 2026 09:42
c82f559 to
ec4d2ba
Compare
kanurag94
marked this pull request as ready for review
July 25, 2026 09:43
kanurag94
requested review from
agrawroh,
botengyao and
yanavlasov
as code owners
July 25, 2026 09:43
Signed-off-by: Anurag Aggarwal <kanurag94@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Commit Message: reverse tunnel: read handshake headers from the live extension
Additional Description:
The reverse-connection listen socket grabs a snapshot of the handshake formatters when it's created. Problem is, that can happen before
onServerInitialized()builds them — so the snapshot is null, and since the same socket config gets reused for every re-dial, the handshake keeps going out with the rawadditional_headerstemplate instead of the resolved value.So a header like
authorization: B**rer %FILE_CONTENT(/etc/tunnel-jwt/token.jwt)%gets sent literally, on every dial.Fix: when we assemble the handshake, read the formatters straight from the live extension instead of trusting the snapshot. Fall back to the snapshot only if the extension has none built.
This is a follow-up to #46168 — that one fixed the same symptom in the extension constructor, but didn't cover the
socket() => io_handle => wrappersnapshot path.Risk Level: Low
Testing: Added a new test to exercise the actual path. It asserts the snapshot is null at socket creation, then that the dial after init sends the resolved value
Docs Changes:
Release Notes:
Platform Specific Features: