Skip to content

Support for X-Envoy-Original-Path, similar to existing support for X-Forwarded-Prefix #4732

@shalako

Description

@shalako

In cloudfoundry/gorouter#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: envoyproxy/envoy#5528.

Metadata

Metadata

Assignees

No one assigned

    Labels

    in: webIssues in web modules (web, webmvc, webflux, websocket)status: declinedA suggestion or change that we don't feel we should currently apply

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions