Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
shalako opened this issue Jan 10, 2019 · 3 comments
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

Comments

@shalako
Copy link

shalako commented Jan 10, 2019

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.

@shalako
Copy link
Author

shalako commented Jan 10, 2019

cc @nebhale

@rstoyanchev rstoyanchev added the status: waiting-for-triage An issue we've not yet triaged or decided on label Jan 12, 2019
@bclozel
Copy link
Member

bclozel commented Apr 1, 2020

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.

@rstoyanchev rstoyanchev added the in: web Issues in web modules (web, webmvc, webflux, websocket) label Nov 10, 2021
@bclozel
Copy link
Member

bclozel commented Feb 18, 2022

Declining as we'd rather stick to the RFC here.

@bclozel bclozel closed this as completed Feb 18, 2022
@bclozel bclozel added status: declined A suggestion or change that we don't feel we should currently apply and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Feb 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Projects
None yet
Development

No branches or pull requests

3 participants