Okhttp: GET BUG in 4.4.0

[MS893]

Hi,

When I perform a GET on this URL : "https://hopteam.hop.fr" using 4.3.1 version, it works fine (response is 200)

If I do the same GET with 4.4.0, responses is 404

Here is my code
request = new Request.Builder() .url(url_hopteam) .build(); response = client.newCall(request).execute();

The client is
client = new OkHttpClient.Builder() .connectTimeout(28, TimeUnit.SECONDS) .writeTimeout(20, TimeUnit.SECONDS) .readTimeout(28, TimeUnit.SECONDS) .addNetworkInterceptor(new LoggingInterceptor()) .cookieJar(cookieJar) .connectionSpecs(Arrays.asList(ConnectionSpec.MODERN_TLS, ConnectionSpec.COMPATIBLE_TLS)) .build();

In my app build.gradle, I have
implementation 'com.squareup.okhttp3:okhttp:4.4.0'

In the project build.gradle, I have
classpath 'com.android.tools.build:gradle:3.5.2'

[MS893]

[yschimke]

I suspect this is a server misconfiguration, potentially triggered by a subtle change in OkHttp behaviour with redirects, connection coalescing and DNS ordering.

$ okurl --debug https://hopteam.hop.fr 2>&1 | grep Location
11:40:19.114    Location: https://office.hop.fr/opensso/saml2/jsp/spSSOInit.jsp?metaAlias=/MSAD/sp&idpEntityID=http://madfs.hop.fr/adfs/services/trust&NameIDFormat=urn:oasis:names:tc:SAML:2.0:nameid-format:transient&binding=HTTP-POST&goto=https://hopteam.hop.fr/home
11:40:19.514    Location: https://madfs.hop.fr/adfs/ls/?SAMLRequest=...

It's failing on the 3rd request.

cc @swankjesse Maybe another symptom of the redirects in dev related issue.

I'll check the certificates to confirm this.

[swankjesse]

Did we inadvertently started coalescing http/1 connections? Other scarier regression would be coalescing redirect calls without a 2nd DNS check

[yschimke]

~I suspect the latter.~

[yschimke]

$ nslookup hopteam.hop.fr | grep Address
Address: 193.84.89.75
$ nslookup madfs.hop.fr | grep Address
Address: 195.101.59.153
$ nslookup office.hop.fr | grep Address
Address: 195.101.59.155

[yschimke]

Cert indicates this is fine

[yschimke]

It does look like it's affecting HTTP/1.1 - but not strongly confirmed.

n.b. For HTTP/2 - A reminder of the difference in Firefox and Chrome connection coalescing

https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/

The Firefox way

Host A has two addresses, host B has two addresses. The lists of addresses are not the same, but there is an overlap – both lists contain 192.168.0.2. And the host A has already stated that it is authoritative for B as well. In this situation, Firefox will not make a second connect to host B. It will reuse the connection to host A and ask for host B’s content over that single shared connection. This is the most aggressive coalescing method in use.

The Chrome way

Chrome features a slightly less aggressive coalescing. In the example above, when the browser has connected to 192.168.0.1 for the first host name, Chrome will require that the IPs for host B contains that specific IP for it to reuse that connection. If the returned IPs for host B really are 192.168.0.2 and 192.168.0.3, it clearly doesn’t contain 192.168.0.1 and so Chrome will create a new connection to host B.

Chrome will reuse the connection to host A if resolving host B returns a list that contains the specific IP of the connection host A is already using.

[yschimke]

@MS893 Thanks for the detailed bug report!

[swankjesse]

I just published 4.4.1 to Maven Central. It should be available in under an hour.

[MS893]

You are the best team ! Thank you, I'm happy if I was useful.