Literal rewriting: the host header is rewritten to a statically defined value
Automatic rewriting: the host header is rewritten with the DNS name or endpoint hostname of the selected envoy cluster.
Header-based rewriting: envoy rewrites the host header with a value consumed from a different header. The different header name is statically defined in
Path regex rewriting: the host header is rewritten with a value derived by applying a regex to the request path.
Unlike other headers, it's safer to rewrite the host header in the forwarding phase, to avoid possible issues related to failed route recalculation after the header is rewritten. Envoy's host rewrite feature are implemented in this way.
Gateway-API and Envoy gateway support literal host rewriting.
Scenarios:
Automatic rewriting: When multiple backends are configured (e.g. for weighted traffic splitting), it could be necessary to rewrite the hostname automatically, based on the dynamically selected backend.
Header-based rewriting: allows envoy to rewrite the host header based on information provided as a hint by the end user or extracted from the request (e.g. a jwt claim with the desired target host header transformed to a header)
Path-Regex rewriting: rewriting to a subdomain that is encoded as a path parameter in a request to the top-level domain.
Envoy Gateway can support additional host rewriting options by adding new options to a policy or implementing EG-specific HTTP Route Filters.
Application developers are the likely users of this feature, as they know the desired host header value and structure in the backend.
Prior art: these features are supported by some gateways in the K8s space:
Nginx Ingress support the annotation upstream-vhost, which can be used to inject dynamic values such as value from other headers, using nginx variables, e.g. nginx.ingress.kubernetes.io/upstream-vhost: $http_x_custom_header
Gloo Edge supports all of envoy's host rewrite options: hostRewrite, autoHostRewrite, hostRewritePathRegex, hostRewriteHeader
Contour, Ambassador and Istio support literal host rewriting only.
Description:
Envoy supports multiple host header rewriting options:
Unlike other headers, it's safer to rewrite the host header in the forwarding phase, to avoid possible issues related to failed route recalculation after the header is rewritten. Envoy's host rewrite feature are implemented in this way.
Gateway-API and Envoy gateway support literal host rewriting.
Scenarios:
Envoy Gateway can support additional host rewriting options by adding new options to a policy or implementing EG-specific HTTP Route Filters.
Application developers are the likely users of this feature, as they know the desired host header value and structure in the backend.
Prior art: these features are supported by some gateways in the K8s space:
nginx.ingress.kubernetes.io/upstream-vhost: $http_x_custom_header
hostRewrite
,autoHostRewrite
,hostRewritePathRegex
,hostRewriteHeader
Relevant Links