This notably allows the mockwebserver project to be run on Android.
ServerSocket only implements Closeable since Java 1.7 and thus calling of
closeQuietly(Closeable) with a ServerSocket argument fails when running
on Java 1.5 or 1.6 JVMs. This is the same as is already done for
closeQuietly(Socket).
This was causing some SPDY connections to be evicted early,
and preventing connection reuse.
The spdyConnectionReuse test becomes flaky with the
fix that makes MockWebServer use different sequenceNumbers
for different requests on the same socket. With the fix
the test is no longer flaky. The old test wasn't good enough
to detect what it wanted to detect!
This race has existed in the code since we added more
aggressive time-based expiration in January 2013. In my
basic tests the race impacted ~20% of connections on a
desktop VM. It may have been more on mobile.
This change is a combination of 4 separate commits
to fix various bugs observed during android platform
testing.
https://android-review.googlesource.com/#/c/63781/
--------------------------------------------
Allow certificate inspections after connect.
We don't have to wait for the request to be sent
before allowing inspection of SSL certs. They can be
inspected as soon as the connection is established.
Fixes CTS test UrlConnectionTest#testInspectSslAfterConnect
https://android-review.googlesource.com/#/c/63821/
---------------------------------------------
Respect read timeout on recycled connections.
Partial fix for CTS test : URLConnectionTest#testGetKeepAlive.
https://android-review.googlesource.com/#/c/63782/
-----------------------------------
Fix HttpUrlConnection#isUsingProxy.
The earlier implementation disregarded what the
ProxySelector had to say. We now query the selected
route (if one has been established).
Fixes compatibility test:
HttpURLConnectionTest#testUsingProxySelector
https://android-review.googlesource.com/#/c/63872/
--------------------------------------------
Don't support anything other than Basic auth.
We should disregard authentication schemes other than
"Basic" and let clients handle them themselves.
The java Authenticator API gives us a user name and
password combination, but we can't know how to format
that information for any scheme other than basic.
Historically:
The JB implementation responds to challenges from an
arbitrary scheme "X" by sending a header with scheme
"X" but formatted like the "Basic" scheme.
The current implementation responds to challenges from
an arbitrary scheme "X" by sending a header with scheme
"Basic" and formatter like the "Basic scheme".
Partial fix for test cases in URLConnectionTest:
- testAuthenticateWithCommaSeparatedAuthenticationMethods
- testAuthenticateWithMultipleAuthenticationHeaders
This is closer to the semantics of HTTP/2.0, which uses the HEADERS
frame for all three types. SPDY is a bit more strict because it
relies on redundancy; it's an error to send a SYN_REPLY after a
HEADERS frame. With HTTP/2.0, there's only one type so there's
no error to detect.
Optional dependencies get included in the fat jar but are not transitive. Provided dependencies do NOT get included in the fat jar and are also not transitive.
I believe the former is a bug in the Maven assembly plugin so the latter case is used as a workaround.
