You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Sorry for asking questions on an closed Issue, but the current implementation of the ServletUriComponentsBuilder does ignore Forward Headers. But the javadoc suggests otherwise. We are now a little bit confused what should be done and what is the expected behaviour.
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 theForwadedHeaderFilter
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 aremoveOnly
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 useUriComponentsBuilder.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:
Referenced from: commits 4da43de
0 votes, 6 watchers
The text was updated successfully, but these errors were encountered: