Support for X-Forwarded-headers

[mloskot]

A follow-up to the discussing during today's community meeting and the features (gaps) collection in #12910, I'd like to seed the idea of having support for the proxy headers.

A very basic use-case:
If HTTPRoute configures path-based routing for a service on example.com host and /myapp path, then request at GET https://example.com/myapp/xyz/echo could reach the backend service as /xyz/echo but with the following headers set by the proxy (gateway):

X-Forwarded-Host	"example.com"
X-Forwarded-Port	"443"
X-Forwarded-Proto	"https"
X-Forwarded-Path	"/myapp/xyz/echo"
X-Forwarded-Prefix	"/myapp"

that is both, de-facto standard and non-standard headers.

It is not uncommon that backend services hosted behind proxy servers rely on those headers e.g. ASP.NET Core apps. As a user of Kong Gateway / Ingress Controller, which supports X-Forwarded-Prefix, Kong/kong#5620, I've taken care to teach my apps to rely those headers.

Second, but also important feature is easy way to enable stripping of prefix from the original request when forwarding request to backend service like the Kong option strip_path. That is, to ensure path part used by gateway routing is stripped from the request forwarded to the target service.
However, that seems to be already feasible with URLRewrite, for example (warning: Gateway API rookie here):

    matches:
    - path:
        type: PathPrefix
        value: /myapp
    filters:
    - type: URLRewrite
      urlRewrite:
        path:
          type: ReplacePrefixMatch
          replacePrefixMatch: /

Perhaps this idea is sensible for kgateway too, despite that majority of the X-Forwarded-* are non-standard HTTP headers.

[yuval-k]

for context, from envoy docs:

• X-Forwarded-Host - should be set automatically if host rewrite is configured. do you want it sent regardless (envoy has a setting on the route for that)?
• envoy supports setting x-forwarded-port automatically, but this is configured on the listener level - you can't turn it off to specific routes. is that ok?
• envoy sets x-envoy-original-path when path is stripped.

If you need more flexibility than what envoy offers, I think you can achieve part of this today with existing head modification filter in the HTTPRoute. suggestion for headers to add:

• X-Forwarded-Path with value %PATH(WQ:ORIG)%,
• X-Forwarded-Host with value %REQUEST_HEADER(:AUTHORITY)%
• X-Forwarded-Port with value %DOWNSTREAM_LOCAL_PORT% or %DOWNSTREAM_DIRECT_LOCAL_PORT%

(havn't tested these ones specifically - i think it's worth a try as these should work today)

see this for more info on the formatters: https://github.com/envoyproxy/envoy/blob/2546bcd78a06fce31a77f90badd2f33878aa36c0/docs/root/configuration/observability/access_log/usage.rst

[mloskot]

can achieve part of this today with existing head modification filter in the HTTPRoute.

The filters and formatters seem very interesting, with potential to solve all those needs indeed. Thank you!

envoy sets x-envoy-original-path when path is stripped.

Yes, that is what I had learned form Envoys docs at one point too. But, it is unfortunate Envoy decided to use custom name instead of supporting X-Forwarded-Path even if it is non-standard. There is a chance existing apps already support the generic X-Forwarded-Path. Teaching many apps about the Envoy-specific equivalent is harder than teaching Envoy to support X-Forwarded-Path.

[yuval-k]

no prob. note that if you don't want to apply them on every HttpRoute rule, you should be able to use the headerModifiers in a TrafficPolicy and attach the policy to multiple HttpRoutes/Gateways.

note that %PATH(WQ:ORIG)% will take the value from x-envoy-original-path - i.e. the path before it was transformed by envoy.