cluster_header router & golang cluster_specifier plugin ignore headers added by envoy's http filters about envoy HOT 5 CLOSED

The cluster_xxx features in the route action are invoked during the route match. So the headers added in the HTTP filter, which is chosen after the route match, won't affect the behavior of cluster selection.

from envoy.

I don't try them myself but there may be some ways to satisfy your requirement:

1. break down the adding header logic and cluster selection, so the cluster will be dynamically set via cluster-specific plugin without setting the header.
2. find some way to clear route cache and update the cluster: https://www.envoyproxy.io/docs/envoy/latest/intro/life_of_a_request#http-filter-chain-processing. There may be some side-effect.

from envoy.

break down the adding header logic and cluster selection, so the cluster will be dynamically set via cluster-specific plugin without setting the header.

Yes I think this is the best way. If the ability to read all existing headers is added to the golang cluster_specifier plugin then I can read the headers, decide on a cluster and then route to it - using only a single filter and within the route action section. This will remove the need to clear the route cache on every request.

I see now from the doc that you shared that a route is chosen before the HTTP filters are run, as stated here:

When decodeHeaders() is invoked on the router filter, the route selection is finalized and a cluster is picked. The HCM selects a route from its RouteConfiguration at the start of HTTP filter chain execution. This is referred to as the cached route. Filters may modify headers and cause a new route to be selected, by asking HCM to clear the route cache and requesting HCM to reevaluate the route selection.

But it's a bit confusing because in other places in the Envoy docs they strongly imply that the router filter will run after the HTTP filter chain, as per point 6 in the request flow section:

For each HTTP stream, an Downstream HTTP filter chain is created and runs. The request first passes through CustomFilter which may read and modify the request. The most important HTTP filter is the router filter which sits at the end of the HTTP filter chain. When decodeHeaders is invoked on the router filter, the route is selected and a cluster is picked.

from envoy.

6e3d574
HeaderMap.Set won't clear route cache by default, it's first introduced in 1.30.0.
You need to clear route cache by using ClearRouteCache instead.

from envoy.

Yep, api.FilterCallbackHandler.ClearRouteCache enables the header change to take effect

Thank you for the information.

Once the capability to read the entire HeaderMap is added to the cluster_specifier it will remove the need to clear the route cache

from envoy.