It looks like servlet.getServletPath() returns a decoded path, even though the request contains an encoded one. Then, the request is rewritten by ProxyTargetUrlBuilder to create the request path for destination server. We could use UriComponentsBuilder to encode the path back but it just seems safer to use getRequestURI() which returns the original requested encoded URI that can be redirected into the destination server. And this solution has been proposed in this PR.
Additionally, a few tests have been refactored to use the real ProxyTargetUrlBuilder logic instead of mocking it.
It looks like
servlet.getServletPath()
returns a decoded path, even though the request contains an encoded one. Then, the request is rewritten byProxyTargetUrlBuilder
to create the request path for destination server. We could useUriComponentsBuilder
to encode the path back but it just seems safer to usegetRequestURI()
which returns the original requested encoded URI that can be redirected into the destination server. And this solution has been proposed in this PR.Additionally, a few tests have been refactored to use the real
ProxyTargetUrlBuilder
logic instead of mocking it.More literature about the URI encoding in Spring: https://stackoverflow.com/questions/966077/java-reading-undecoded-url-from-servlet https://stackoverflow.com/questions/4931323/whats-the-difference-between-getrequesturi-and-getpathinfo-methods-in-httpservl