x-forwarded-port can have incorrect value when Spring Cloud Gateway not the first proxy in the chain

Setup as follows, Spring Cloud Gateway proxying Spring Data Rest API, via http, running on Google Kubernetes Engine over TLS. TLS terminates on the gcloud http load balancer created by the kubernetes ingress.

Google HTTP LB adds the following headers to the request

x-forwarded-for: <usual content>
x-forwarded-proto: https

Spring Cloud Gateway then amends x-forwarded headers as follows

x-forwarded-for: <usual content>
x-forwarded-proto: https,http
x-forwarded-port: 80

Spring Data Rest / Spring Hateoas then creates URIs with the wrong port, to get this to work properly I had to strip the x-forwarded-port header and manually add one like this to match x-forwarded-proto

x-forwarded-port: 443,80

Looking at the zuul code it seems they base x-forwarded-port off x-forwarded-proto whereas for Spring Cloud Gateway these headers are independent. Not that zuul is the be all and end all of functionality but I’m converting over from zuul to gateway, and found this issue hence the comparison because I was curious.

Not sure what would happen on other cloud providers, Spring Cloud Gateway worked for http and https when it terminates the TLS.

Test project https://github.com/RobMaskell/gatewayissues

[tillmannheigel]

Sorry for the confusion, I mixed up two concepts:

a) The Forwarded Http Extension (rfc7239) which is in Spring Cloud Gateway taken into account in ForwardedHeadersFilter.java

b) The non-standard X-Forwarded-* header fields (XForwardedHeadersFilter.java)

Nevertheless, after reading rfc7239, the interpretation from above stays the same: While for should amend all the proxies, should proto identifiy the protocol between the client and the first proxy:

• “for” identifies the node making the request to the proxy.
• “proto” indicates what protocol was used to make the request.

(src: rfc7239, p. 5)

XForwardedHeadersFilter has some defaults which can be changed by configuration properties: e.g.

spring.cloud.gateway.x-forwarded.proto-enabled=[true] spring.cloud.gateway.x-forwarded.proto-append=[true] spring.cloud.gateway.x-forwarded.for-enabled=[true] …

We should think about the defaults (but in a separate ticket/issue) and add the same functionality to the ForwardedHeadersFilter (also a separate ticket/issue). Last but not least I discovered a broken behaviour in ForwardedHeadersFilter if it isn’t the first proxy (I will create a third ticket).

Hope that clarified something…

[RobMaskell]

When there is a proper standard, as in the case of the Forwarded header the yes follow it to the letter. But in the case of X-Forwarded-* because they are non standard by definition you have to try and make to work in as many real world situations as you can.