-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Appending to the X-Forward-Prefix Header appends path with comma #1772
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
Comments
We, spring, made up that header IIRC. X-Forwarded headers are cumulative. So this header behaves like other X-Forwarded headers. |
I think changing the filter in Spring to support this would be a valid
option as well. That would break paths containing actual commas though - an
edge case but I’m pretty sure those are legal.
…On Thu 11. Jun 2020 at 01:32, Spencer Gibb ***@***.***> wrote:
We, spring, made up that header IIRC. X-Forwarded headers are cumulative.
So this header behaves like other X-Forwarded headers.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1772 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABBRN7ZAQQ2KKOMPCKVTYFDRWAJ2BANCNFSM4N22S4IA>
.
|
That's standard multi value http headers |
Sure, but when I see I can take this over to spring-framework, feel free to close this here. |
Sure, open something there and we can see what they say. |
I'm currently using spring-cloud gateway behind another reverse proxy. Both strip a path component and both set an X-Forwarded-Prefix header accordingly. This leads to spring-cloud-gateway appending it's path component to the existing X-Forward-Prefix Header with both components being separated by a comma.
This breaks Spring's ForwardedHeaderFilter, since it just uses the header's content to prefix the request path. I also couldn't find any other source describing this behaviour for X-Forwarded-Prefix - MDN describes this for X-Forwarded-For.
Some form of compatibility with Spring's ForwardedHeaderFilter (and probably other implementations which assume they can just prefix a path with the contents of X-Forwarded-Prefix would be preferable to the current behavior.
The text was updated successfully, but these errors were encountered: