Kai Moritz (Migrated from SEC-1500) said:
This issue is simmilar to the issue SEC-1255 "Target-URL after successfull login differes from original URL, when it was encoded according to RFC 3986"
When switching the channel, AbstractRetryEntryPoint rebuilds the URL from its decoded parts.
So, when switching on a URL, that containes a special character (like '?'), which is encoded according to RFC 3986, it changes the URL.
For example, the URL "/foo%3Fbar.html", where "%3F" encodes the "?", becomes "/foo?bar.html", which is not encoded correctly, thus resulting in a 404-Error.
Encoding the rebuild URL would not work, becaus all special characters (like contained slashes for example) would be encoded than, which is, as far as I know, not correct.
I fixed the issue in my local git repository by calling the UrlUtils, which were fixed in issue SEC-1255, for building the redirect URL.
I will apply my patch to this bug-report.
Kai Moritz said:
This is my patch for the AbstractRetryEntryPoint.
Because UrlUtils appends a "://" to the scheme-parameter, I also had to patch RetryWithHttpEntryPoint and RetryWithHttpsEntryPoint.
Luke Taylor said:
Thanks for the patch. There are some minor problems with it (such as potential NPEs due to autoboxing) and it results in absolute URLs for all redirects (which should not be a problem but breaks tests). To keep things as simple as possible I've just modified the existing code to use the requestURI itself. The details may be revisited as part of SEC-1413, which would supersede these changes.
This issue is related to #1656