Rossen Stoyanchev opened SPR-16668 and commented

Currently "Forwarded" headers are consumed indirectly when building links with ServletUriComponentsBuilder, MvcUriComponentsBuilder or in CORS checks. While the behavior is documented, it can be overlooked, and it would be better to differ the treatment of such headers to the ForwadedHeaderFilter which requires an explicit choice, handles such headers more efficiently (once per request), is more comprehensive as a solution (e.g. applies to redirects too), and provides a removeOnly flag which can discard such headers when the application is not behind a trusted proxy.

On the implementation level we would keep the current UriComponentsBuilder.fromHttpRequest which encapsulates the actual handling of such headers, and switch the above to use UriComponentsBuilder.fromUri instead.

In the mean time, applications can use the ForwadedHeaderFilter which removes those headers (by wrapping the request), either consuming or ignoring them, and thus providing a single point of handling.

Affects: 5.0.4

Issue Links:

• DATAREST-1264 Adapt to changed forwarded header behavior
• Process X-Forwarded-Ssl headers properly [SPR-16863] #21402 Process X-Forwarded-Ssl headers properly
• UriComponentsBuilder Forwarded header parsing can throw java.lang.NumberFormatException [SPR-16660] #21201 UriComponentsBuilder Forwarded header parsing can throw java.lang.NumberFormatException
• UriComponentsBuilder injected into a WebFlux controller method argument uses the full URI [SPR-16813] #21353 UriComponentsBuilder injected into a WebFlux controller method argument uses the full URI
• Misleading JavaDoc in ServletUriComponentsBuilder [SPR-17317] #21850 Misleading JavaDoc in ServletUriComponentsBuilder
• Process X-Forwarded-Ssl headers properly [SPR-16863] #21402 Process X-Forwarded-Ssl headers properly

Referenced from: commits 4da43de

0 votes, 6 watchers