Similar to HTTP and Call, the WebSocketCall is a representation of a pending HTTP request and subsequent upgrade to speak web sockets. Upon synchronous execution you are handed a WebSocket instance for synchronous writing and also pass in a WebSocketListener for async callbacks due to reading.
The API changes in this commits also generalize WebSocket such that it's agnostic to being a client or server peer.
Most applications won't want to disable retry globally. Instead, use
clone() to get an OkHttpClient for a specific, non-idempotent request,
then configure that client with the setting.
Closes https://github.com/square/okhttp/issues/1043
The structure here is a bit ugly. But it permits a single 'synchronized'
block, which makes the method easier to reason about.
Closes https://github.com/square/okhttp/issues/1239
The trickiest part of this change is the SOCKS 5 proxy implemented
to make testing possible. Fortunately the protocol is very easy, and
shows off Okio.
Closes https://github.com/square/okhttp/issues/1009
Previously two OkHttpClients that shared a connection pool but
used different proxy selectors could incorrectly share the
pooled addresses.
Closes https://github.com/square/okhttp/issues/1149
Also fix a bug in MockWebServer where calls to shutdown()
raced with calls to play() would throw a NullPointerException.
Also improve logging in MockWebServer.
* nfuller/FixPoolLeak:
Fix for a socket leak in OkHttp on Android
Conflicts:
okhttp-tests/src/test/java/com/squareup/okhttp/ConnectionPoolTest.java
okhttp/src/main/java/com/squareup/okhttp/ConnectionPool.java
This is a binary-compatible change, but code that currently calls
RequestBody.contentLength() doesn't necessarily catch or declare
IOException, and will need to with this change.
MultipartBuilder is most impacted by this change; previously the
length was computed eagerly; now it's not computed at all.
Applications that require the previous behavior should fully
buffer the request bodies and use that to compute the length.
Closes https://github.com/square/okhttp/issues/1141
These exist between the OkHttp features (gzip, response cache, retry, route
planning, etc.) and the network server. They can be used to rewrite the response
headers and body from what the server actually returned to what the client wants.
For example, the interceptor could inject a missing 'Cache-Control' header to make
caching work better.
This is necessary to unblock network interceptors, where the interceptor
may elect to rewrite the response body. If we've already cached the
original response body, we're too late.
When the preferred Android network changes from
cell -> wifi or wifi -> cell the HTTP connection
pool in use is abandoned to avoid reuse of
connections on the old network. This was added
in commit 8bced3e.
The design for the connection pool was such that
continuous use of the connection pool was required to
clean up idle / expired connections. If a connection
pool becomes idle (as when it is dereferenced on a
network change) it is possible for some connections
to remain in the pool indefinitely.
After the preferred network change, because the old
connection pool was no longer referenced the pool
would be garbage collected and Android's "Strict Mode"
would complain about sockets not being closed.
The only existing way to avoid this was to call
"evictAll()", which would have had issues when a
large number of connections were returned to the pool
after evictAll() was called. It also wouldn't work
for SPDY connections which are shared but not reference
counted, which makes knowing whether it is safe to
close them difficult.
The cleanModeRunnable serves two purposes:
1) While scheduled / executing, it pins the connection
pool in memory to avoid it being garbage collected.
2) It continues to close connections (safely) until the
pool is empty.
If a connection is then added back to the pool the
cleanModeRunnable is restarted.
