What happened
We were using spring webflux with spring boot gradle plugin 3.3.5 and we upgraded to 3.4.0.
With this version locally nothing happened however when deploying the app was broken and our calls ended in 404.
After digging it seems to be caused by forward-headers-strategy:native that did nothing before and that now prefix routes with the value of the X-forwarded-prefix header.
The trick is that we never set this property to native but it seems to be automatically configured based on environment variables when running on kubernetes and that made it worse because we couldn't know the issue was present before deploying and it was hard to reproduce the issue locally unless knowing that some header related configuration is done automatically based on the cloud platform.
Comment From: wilkinsona
Thanks for the report. Sorry to hear that you were caught out here, but the default of native on a supported cloud platform is documented. Assuming that you're using WebFlux in its default configuration, then the embedded web server with be Reactor Netty and any change in behavior will have to be addressed there.
Comment From: TheBatman09
Thanks for your quick answer. Just to be sure I'm getting this right:
The real issue I was reporting here is not that native is set by default, but also that configuring the strategy to native did nothing before and now it changes the route of the request. This is a netty behavior and not spring boot right ? (sorry to insist i'm asking because I read somewhere that a spring boot filter was responsible for this)
Comment From: bclozel
@TheBatman09 I think this is related to this change: https://github.com/reactor/reactor-netty/issues/3432
Previously Reactor Netty was not supporting this header and now it does; note, it was supporting already the other "X-Forwarded-*" headers (host, port, etc). Spring Boot enables the "native" strategy for applications deployed on the cloud 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 disable this option entirely and set it to "none". In this case, we would be interested to know which platform you are using, the type of clients sending those headers and why they shouldn't be considered by the application.
Comment From: TheBatman09
Ok I think I get it thank you !
Well the app behind a proxy but the none strategy is working fine for me, we only needed the headers to generate correct hateos links but we do not need the request to be changed in any way.