Include X-Forwarded-Prefix header in 'allowForwarded' implementation

[chefhoobajoob]

Describe the feature

vertx support of X-Forwarded-* header processing should consider including support for the non-standard but actively used X-Forwarded-Prefix header, which provides path prefixes that the client's original url included, typically used with api gateways like apigee, kong, and others. Spring Boot includes support for this in their X-Forwarded-* support.

Use cases

Example description here: https://github.com/envoyproxy/envoy/issues/5528

[pmlopes]

@chefhoobajoob envoy rejected the issue, claiming that there are now standard headers for this (the ones vertx-web, also follows).

While X-Forward-{For|Proto|Port} do seen quite common, Prefix is not common and many proxies seem reluctant to allow/accept it.

The quick workaround is to have a handler that inspects that header and strips it from the context uri.

[pmlopes]

References:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Forwarded https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/x-forwarded-headers.html

[chefhoobajoob]

@pmlopes : I think the issue at Envoy was not closed as a rejection, but was auto-closed due to inactivity. While it is true there is an early comment on that issue claiming that there are alternative "standard" headers to communicate these additional path elements, there is no such other header, and this is acknowledged in a later comment by that same user. I only provided the issue reference here for its description of the use case for the header.

The example cited to motivate its inclusion in vertx-web is its inclusion in analogous support from Spring Boot back in 2016, and its ongoing support today, even as they have revised their internals over the years.

Separate question: is the X-Forwarded-* support targeted for a future 3.9.x release, or only for 4.x?

[scrocquesel]

This concept has been around in Microsoft ecosystem, as far a i can remember, in IIS5 since early 2000. IIS has a concept of virtual path to mount multiple applications on the same virtual host using subdirectories. That way, the application can route requests by matching request path property containing only the "inner" path value but still has access to a request path base property with only the stripped segment. Concatenating both results in the real absolute uri.

This allow for static subrouting but as a collateral effect, it also allow supporting dynamic subrouting in the Microsoft world (dotnet core now). It is as simple as 5 lines of code, mangling request path and request basePath values early in the request processing. It is fully transparent to the application and the same instance of an application can be exposed on multiple ingress endpoint with different combinations of host/port/scheme and base path. Which header the ingress proxy used to communicate such an information is up to the developer. It is true and very sad that no RFC cover this but solution editors seem to converge on x-forwarded-prefix. Even Microsoft is aligning with the community https://github.com/microsoft/reverse-proxy/issues/737

I guess that since 2.2.0, Spring Boot adopts a similar strategy and rewrite HttpServletRequest contextPath, path, and uri accordingly.