Silent "error" when a 302 redirect url is malformed

I’m seeing a case in handling redirects where it appears that okhttp isn’t following a redirect. After digging through okhttp with the failing url, okhttp is functioning “correctly” - the redirect url is invalid. Therefore, okhttp doesn’t follow the redirect, and returns a response with response code 302.

A test illustrating this:

Request request = new Request.Builder().url(originalUrl).build();
Response response = okhttp.newCall(request).execute();

log(response.code());
log(response.isSuccessful());

results in:

302
false

Example for originalUrl:

<originalUrl>, <host>, and <paths> have been used as substitutes for real urls, hosts, and paths

<-- 302 Found <originalUrl>
Date: Sun, 07 Jan 2018 17:04:43 GMT
Server: Apache/2.4.10 (Debian) PHP/5.6.24-0+deb8u1 OpenSSL/1.0.1t
X-Powered-By: PHP/5.6.24-0+deb8u1
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Location: http://.<host>/<path>
Access-Control-Allow-Origin: *
Connection: close
Content-Type: text/html; charset=UTF-8
<-- END HTTP

And yes, followRedirects and followSslRedirects are enabled

What’s going on here is that the 302 redirect location is an illegally formatted URL - in my case, something like http://.<somehost>/<path> (note the leading . to the hostname). OkHttp’s RetryAndFollowUpInterceptor reads this Location, and tries to parse it with HttpUrl. That, correctly, fails. At this point, the retry interceptor just returns and allows the 302 to propagate up: https://github.com/square/okhttp/blob/cd84d79c3574de81f23802f832f2ead6ad38a735/okhttp/src/main/java/okhttp3/internal/http/RetryAndFollowUpInterceptor.java#L307-L312

Now, any sane client should be able to detect that the end response is not successful and handle it gracefully. But through reading through app logs, there’s no indication as to what the actual failure was. The failed url parsing on the redirect location is simply swallowed here deep in OkHttp, without any mechanism to inform the client that the error occurred.

Should a failed HttpUrl parse be bubbled up as an exception?

[swankjesse]

That’s an attempt to redirect to a file: URL. I didn’t get anything satisfying attempting to get Chrome and Firefox to redirect to broken URLs; they appear to just hang.

I don’t think OkHttp should throw when it has a response, even if that response is a malformed redirect. Throwing prevents the application layer from inspecting the HTTP response body, and that might have some clues around what went wrong.

[swankjesse]

I think returning the 302 is our best option here.