I have a Spring Boot application, with Webflux, that receives requests from a Kong server. I receive these requests via a generic RestController and handle they differently based on the request's path. But recently, after I upgraded the Spring Boot's version from 3.3.8 to 3.4.2, the path I'm getting isn't what I expect for the same request.

GenericController.java

@PostMapping(value = "**", produces = MediaType.APPLICATION_JSON_VALUE)
public Mono<ResponseEntity<byte[]>> genericPost(
        @RequestBody byte[] body,
        @RequestHeader HttpHeaders headers,
        ServerHttpRequest request) {

    log.trace("> getURI {}", request.getURI());
    log.trace("> getPath {}", request.getPath());

Spring Boot 3.3.8

> getURI /
> getPath /

Spring Boot 3.4.2

> getURI /
> getPath /v1/api/service/

The Kong service is configured with "strip_path: true", so the Spring Boot application is receiving the request at /. This can be verified with Spring Boot version 3.3.8. But it seems ServerHttpRequest is showing info from the external request only.

How can I get the internal request info using Spring Boot 3.4.2?

Additional information Here some headers (same for both versions) that may be useful to understand what's happening:

[Host:"my-internal-service:8080", 
Connection:"keep-alive", 
X-Forwarded-For:"xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx", 
X-Forwarded-Proto:"https", 
X-Forwarded-Host:"my-external-host.kong", 
X-Forwarded-Port:"443", 
X-Forwarded-Path:"/v1/api/service", 
X-Forwarded-Prefix:"/v1/api/service", 
X-Real-IP:"xxx.xxx.xxx.xxx"]

Thanks

I have a Spring Boot application, with Webflux, that receives requests from a Kong server. I receive these requests via a generic RestController and handle they differently based on the request's path. But recently, after I upgraded the Spring Boot's version from 3.3.8 to 3.4.2, the path I'm getting isn't what I expect for the same request.

GenericController.java

@PostMapping(value = "**", produces = MediaType.APPLICATION_JSON_VALUE)
public Mono<ResponseEntity<byte[]>> genericPost(
        @RequestBody byte[] body,
        @RequestHeader HttpHeaders headers,
        ServerHttpRequest request) {

    log.trace("> getURI {}", request.getURI());
    log.trace("> getPath {}", request.getPath());

Spring Boot 3.3.8

> getURI https://my-external-host.kong.com/
> getPath /

Spring Boot 3.4.2

> getURI https://my-external-host.kong.com/v1/api/service/
> getPath /v1/api/service/

The Kong service is configured with "strip_path: true", so the Spring Boot application is receiving the request at /. This can be verified with Spring Boot version 3.3.8. But it seems ServerHttpRequest is showing info from the external request only.

How can I get the internal request info using Spring Boot 3.4.2?

Additional information Here some headers (same for both versions) that may be useful to understand what's happening:

[Host:"my-internal-service:8080", 
Connection:"keep-alive", 
X-Forwarded-For:"xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx", 
X-Forwarded-Proto:"https", 
X-Forwarded-Host:"my-external-host.kong.com", 
X-Forwarded-Port:"443", 
X-Forwarded-Path:"/v1/api/service", 
X-Forwarded-Prefix:"/v1/api/service", 
X-Real-IP:"xxx.xxx.xxx.xxx"]

Thanks

• java
• spring-boot
• spring-webflux
• kong

• I believe there was a fix in Spring 6.2 to properly handle all the X-Forwarded for headers, which it initially didn't. – M. Deinum Commented 7 hours ago

1 Answer 1

I think this is related to this particular change in Reactor Netty: https://github.com/reactor/reactor-netty/issues/3432

Previously Reactor Netty was not supporting this HTTP header and now it does. Note, it was supporting already the other "X-Forwarded-*" headers (host, port, etc). This is a behavior change, but you should know that you would have seen that behavior in the past already if you were using Tomcat of the Spring Framework Forwarded filters.

Spring Boot enables the "native" forwarded headers strategy for applications deployed on the cloud (Cloud Foundry, Kubernetes, etc) because a lot of platforms rely on internal proxies and those headers for routing and load balancing. If your application is not meant to handle Forwarded headers in the first place, because you are not behind a proxy or a CDN, then you should set "server.forward-headers-strategy=none".

• Should the application read and trust "X-Forwarded-*" headers? If the Kong proxy is trusted, the application should trust them to get the correct host and protocol
• Should the proxy send this particular "X-Forwarded-Prefix" header or should the application be aware of this forwarded path in its codebase? HTTP headers look right, this is more of a platform design decision