fix: always set original-path internal headers in extproc#2398
fix: always set original-path internal headers in extproc#2398kanurag94 wants to merge 3 commits into
Conversation
The x-envoy-original-path header was only set when unset, so a client-supplied or pre-existing value could survive and shadow the gateway's own value, causing downstream logic (e.g. processor lookup on retry) to key off the wrong path. Set it unconditionally, matching the already-unconditional x-ai-eg-original-path, so extproc is the authoritative writer of the internal headers it owns. Signed-off-by: Anurag Aggarwal <kanurag94@gmail.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2398 +/- ##
==========================================
- Coverage 84.85% 84.85% -0.01%
==========================================
Files 151 151
Lines 22086 22085 -1
==========================================
- Hits 18742 18740 -2
- Misses 2213 2214 +1
Partials 1131 1131 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
dosubot
Bot
added
the
size:S
missBerg
added
bug
|
@gemini review |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request ensures that original-path headers are set unconditionally in extproc to prevent client-supplied values from shadowing the gateway's own values, and adds a corresponding unit test. The review feedback correctly points out that because HeaderValueOption defaults to appending values, the implementation should explicitly set AppendAction to OVERWRITE_IF_EXISTS_OR_ADD to guarantee that pre-existing headers are completely overwritten, and the unit tests should be updated to assert this behavior.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
… extproc Signed-off-by: Anurag Aggarwal <kanurag94@gmail.com>
3 participants
Description
The extproc router filter writes two "original path" internal headers from the incoming request path:
x-ai-eg-original-pathandx-envoy-original-path. The first is set unconditionally, but the second was only set when it was empty. Because of that, a client-supplied or otherwise pre-existingx-envoy-original-pathsurvives and shadows the gateway's own value, and downstream logic that keys off the original path (for example the upstream-filter processor lookup on retry) then operates on the wrong path.This change makes extproc the authoritative writer of the internal headers it owns.
x-envoy-original-pathis now set unconditionally, matching the siblingx-ai-eg-original-path. The header is already treated as gateway-owned elsewhere in extproc (the header mutator ignores it so users can't change it through the header mutation API), so writing it unconditionally simply aligns the two headers' behavior.A unit test is added asserting that pre-existing values on both original-path headers are overwritten with the request path.
Related Issues/PRs (if applicable)
Special notes for reviewers (if applicable)
The MCP proxy sets both original-path headers with set-if-missing semantics when forwarding to its own upstream; that is a separate hop and is not affected by this change. Since the router filter already wrote
x-ai-eg-original-pathunconditionally, this only bringsx-envoy-original-pathin line with existing behavior rather than introducing new behavior.