Add support of additional %UPSTREAM% variables to custom headers

[vinzo99]

One of our customers is using the Envoy tap filter to retrieve transport information and add them to their request/response headers, as documented here : https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/headers.html#custom-request-response-headers

At this point, very few %UPSTREAM% variable names are supported :
%UPSTREAM_METADATA([“namespace”, “key”, …])%
%UPSTREAM_REMOTE_ADDRESS%

They wish additional %UPSTREAM% variables were supported, such as %UPSTREAM_LOCAL_ADDRESS%.

Thanks !

[lambdai]

See my previously raised issue #12236 , the PR is proposed and the discussion.

The major blocker is that retry would change the upstream info and there is no well defined api.

So we need either evolve the route action or see how to adopt this requirement in Http upstream filter upstream http filter

[antoniovicente]

@vinzo99 Do you expect to need the ability to populate %UPSTREAM_LOCAL_ADDRESS% on the request headers sent to the upstream or only on the reply headers proxied back to the downstream? The later is doable, it just needs to be implemented. Are there other pieces of information about the upstream that you'ld like to communicate to the downstream via added reply headers?

@lambdai Yeah, we would need some way to delay computation of said headers and recompute them on retry. We would also need to decide if retries should append to the modified headers or replace the relevant header lines.

[lambdai]

There are several workaround or plans

1. As @antoniovicente mentioned, if the upstream header need to be populated by HCM router filter, the api need to be consistent on execution per-retry mutation, sanitize on retry(append or override)...
2. Done by cluster upstream extension: See example here extension: add test case #13915. This header rewrite is strictly after router rewrite so the new header is invisible to router. Need to use with causion.
3. Http upstream filter is the chance to reorganize the rewrite phases Upstream HTTP filters #10455

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[vinzo99]

Reviving thread