In https://github.com/cloudfoundry/gorouter/issues/229, @lavcraft brought to the Cloud Foundry Routing team's awareness that Spring supports the X-Forwarded-Prefix header (see ForwardedHeaderFilter), and requested that Cloud Foundry's existing perimeter ingress Gateway (called Gorouter) support the header.
This header appears to prevent a developer from having to configure SERVER_SERVLET_CONTEXT_PATH specifically for each environment the app is deployed to, and the framework ensures that links generated for responses are correct when the requested path is different from the served path e.g. requests are made to /foo/bar but app serves the content on /bar; self-referential links must include the path prefix /foo.
In Cloud Foundry we are adopting Envoy as the platform perimeter ingress proxy, so don't want to make the enhancement to Gorouter. Envoy supports the same use case using a header X-Envoy-Original-Path.
Based on the acceleration in popularity of the Envoy project, I wondered if the Spring team would consider supporting the X-Envoy-Original-Path header for the same use case. As a result, Spring apps deployed to Cloud Foundry could benefit when Envoy is used as the perimeter ingress gateway.
I have also opened an issue with Envoy, exploring support for X-Forwarded-Prefix: https://github.com/envoyproxy/envoy/issues/5528.
Comment From: shalako
cc @nebhale
Comment From: bclozel
envoyproxy/envoy#5528 has been closed with very little input from the envoy team. As a Framework, we're trying to stick to established RFCs or well-adopted conventions. Supporting an additional header for a specific product, without any guarantee nor attempt at turning it into a proper standard might not be the best choice here.
Other products seem to rely on using the non-standard path key in the Forwarded header, but that seems to be even riskier.
In the meantime, X-Forwarded-Prefix seems to be the best option until this is considered in a standard header.
Comment From: bclozel
Declining as we'd rather stick to the RFC here.