Support for X-Envoy-Original-Path, similar to existing support for X-Forwarded-Prefix #4732
Labels
in: web
Issues in web modules (web, webmvc, webflux, websocket)
status: declined
A suggestion or change that we don't feel we should currently apply
In cloudfoundry/gorouter#229,
@lavcraft
brought to the Cloud Foundry Routing team's awareness that Spring supports theX-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
: envoyproxy/envoy#5528.The text was updated successfully, but these errors were encountered: