tcp_proxy: Propagate non-2xx response status on CONNECT to client when using internal listeners
Description:
This is the setup:
Client -> Egress HCM -> Entry cluster -> Internal Encap listener -> tcp_proxy(TunnelingConfig, HTTP2 CONNECT) -> Upstream
When the upstream returns 403 on the CONNECT stream, tcp_proxy treats this as a failure to establish the tunnel and resets the downstream connection. The Entry cluster sees cx_connect_fail and we return a 503 to the client.
If we try UPSTREAM_FILTER_STATE(envoy.tcp_proxy.propagate_response_headers) at the egress HCM access log, we find that the filter state is not propagated but propagate_response_headers: true on the encap listener's tcp_proxy does show the 403 which helps for access log visibility at the egress proxy.
It would be really helpful to propagate the 403 back to the egress HCM's client response.
tcp_proxy: Propagate non-2xx response status on CONNECT to client when using internal listeners
Description:
This is the setup:
When the upstream returns 403 on the CONNECT stream,
tcp_proxytreats this as a failure to establish the tunnel and resets the downstream connection. The Entry cluster seescx_connect_failand we return a 503 to the client.If we try
UPSTREAM_FILTER_STATE(envoy.tcp_proxy.propagate_response_headers)at the egress HCM access log, we find that the filter state is not propagated butpropagate_response_headers: trueon the encap listener's tcp_proxy does show the 403 which helps for access log visibility at the egress proxy.It would be really helpful to propagate the 403 back to the egress HCM's client response.