The wiring is definitely a bit more awkward than I would like. The
CertificateAuthorityCountil is a non-public class, and this change
sneaks an instance into the CertificatePinner that couples it to
the OkHttp client's SSLSocketFactory.
A nicer solution is to expose CertificateAuthorityCouncil as a public
API type, and add it to Address.java. Unfortunately that's currently
pretty awkward, especially because I'm not ready to commit to the
name CertificateAuthorityCouncil or its API.
Closes: https://github.com/square/okhttp/issues/1699
Conflicts:
okhttp/src/main/java/com/squareup/okhttp/CertificatePinner.java
okhttp/src/main/java/okhttp3/OkHttpClient.java
The goal of this is to get the root CA certificate into the certificate
chain, so that it can be considered by the certificate pinner. The work
to integrate CertificateAuthorityCouncil with CertificatePinner will
come in a follow-up PR.
See: https://github.com/square/okhttp/issues/1699
Conflicts:
mockwebserver/src/main/java/com/squareup/okhttp/internal/SslContextBuilder.java
okhttp-tests/src/test/java/com/squareup/okhttp/CertificatePinnerTest.java
okhttp-tests/src/test/java/com/squareup/okhttp/URLConnectionTest.java
Right now there's problems with our ability to confirm certificate pins with
root certificates because we don't actually know which certificate authority
was used.
This unblocks that work.
This code is particularly fragile and gross. There's no API to get the
TrustManager from an SSLSocketFactory. We can potentially change the way
that we compute the initial SSLSocketFactory, but this approach is most
general.
This is motivated by https://github.com/square/okhttp/issues/1699
Conflicts:
okhttp/src/main/java/com/squareup/okhttp/internal/Platform.java
okhttp/src/main/java/okhttp3/OkHttpClient.java
This is imperfect, but it should save some unnecessary work and will
hopefully prevent RouteSelector from attempting a route when none is
available.
https://github.com/square/okhttp/issues/2151
There's a few places where OkHttp could leak a connection that needed to be
closed. With our new connection pool model this is easier to find. This fixes
two specific problems:
- too many redirects doesn't release the last used connection
- interceptors that throw runtime exceptions don't release the connection
There are likely more situations. I have hacked together a small little test
harness to make finding these leaks easier; that's not included in this PR.
We still don't implement a limit on the number of open connections.
That needs to come afterwards, and will be difficult because we'll
need to add policy on which connections to evict.
Add a callback invoked on settings changes. The concurrency here
is a little awkward because the calls into the listener are not
serialized.
This is going to be used in a follow up change to keep the
connection's allocation limit in sync.
Previously we could close an SSL socket which does synchronous I/O. This
made it unreasonable to cancel a call on a UI thread.
Closes: https://github.com/square/okhttp/issues/1592
