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

Start with the linked gatewayissues test project and reproduce the request through a TLS-terminating Google HTTP load balancer before reading Spring Cloud Gateway's forwarded-header handling. Compare the generated Spring Data REST or Spring HATEOAS URIs with the forwarded header chain; done means x-forwarded-port remains consistent with the upstream protocol and produces the correct external port.