Patrick Barry created HTTPCLIENT-2377:
-----------------------------------------
Summary: DefaultRedirectStrategy equals on HttpHost is problematic
Key: HTTPCLIENT-2377
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2377
Project: HttpComponents HttpClient
Issue Type: Bug
Components: HttpClient (async)
Affects Versions: 5.5
Reporter: Patrick Barry
In Apache client 5.5, there is new restrictive logic in place around redirects.
[https://github.com/apache/httpcomponents-client/pull/624]
{code:java}
@Override
public boolean isRedirectAllowed(
final HttpHost currentTarget,
final HttpHost newTarget,
final HttpRequest redirect,
final HttpContext context) {
if (!currentTarget.equals(newTarget)) {
for (final Iterator<Header> it = redirect.headerIterator();
it.hasNext(); ) {
final Header header = it.next();
if (header.isSensitive()
||
header.getName().equalsIgnoreCase(HttpHeaders.AUTHORIZATION)
|| header.getName().equalsIgnoreCase(HttpHeaders.COOKIE)) {
return false;
}
}
}
return true;
} {code}
The first line in comparing currentTarget to newTarget will almost always be
true, because currentTarget include port number in the HttpHost, where the
newTarget has not been resolved or something, and does not have that set yet.
currentTarget = [https://mywebservice.com:443|https://mywebservice.com/]
newTarget = [https://mywebservice.com|https://mywebservice.com/]
This does not seem like expected behaviour. This could be updated to
{code:java}
if(!currentTarget.getHostName().equalsIgnoreCase(newTarget.getHostName()))
{code}
A more complicated comparison could look at scheme of "https" and if
currentTarget is https with port of 443 and newTarget is https with no port,
then the same are equal (including address/host of course).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
