| 75144448c1f59f167a1030eb650b606447112083 |
|
25-Oct-2017 |
Tobias Thierer <tobiast@google.com> |
Move of OkHttp facade API to new package.
This CL moves the classes that make up this facade from
libcore.net.http
to
com.squareup.okhttp.internalandroidapi.
In jarjar'ed build targets, this becomes
com.android.okhttp.internalandroidapi.
This facade constitutes the API via which non-libcore parts
of the Android platform (currently framework) may access
OkHttp. It's moving because libcore.net.http is already
part of libcore, and the overlap of packages is problematic for
builds with EXPERIMENTAL_USE_OPENJDK9 set to true.
Http{,s}Handler are not currently imported by framework code;
this CL moves them back to com.android.okhttp. That package is
also where preloaded-classes still expected them to be.
Bug: 68220880
Test: CtsLibcoreOkHttpTestCases
Change-Id: I6f01c1d0f59db43290dac126f6b6ed2071d7708a
/external/okhttp/android/main/java/com/squareup/okhttp/HttpHandler.java
|
| fd27541d8b1efc65c64bd841722830162406d54e |
|
11-Apr-2017 |
Tobias Thierer <tobiast@google.com> |
Isolate OkHttp from frameworks/base.
Introduce a new class libcore.net.http.HttpURLConnectionFactory that
offers a subset of OkHttpClient APIs, suitable for use by Android
framework code as an abstraction layer to avoid tight coupling onto
OkHttp.
Some Android specific classes from android/ have also moved into
that package, with package private methods exposed via new helper
classes that remain in the OkHttp package.
The code added/moved to libcore.net.http remains in the
external/okhttp git repository because unlike libcore itself,
it has compile time dependencies onto okhttp.
Bug: 64021405
Test: libcore.java.net.URLConnectionTest
Change-Id: I85b7082ebb55b9ae000a4b593058d80b889263fd
/external/okhttp/android/main/java/com/squareup/okhttp/HttpHandler.java
|
| 36e73c99548c96ca88c3d26bb82e0114acd46d9a |
|
27-Jan-2016 |
Chad Brubaker <cbrubaker@google.com> |
Use hostname aware isCleartextTrafficPermitted
The cleartext traffic blocking feature of
android.net.NetworkSecurityPolicy is being expanded to provide finer
grained controls (per hostname). This change integrates the OkHttp
stack with these finer grained controls.
Bug: 22666071
Change-Id: I36ffa2f8bd2960cf25cef95b9d11e599c508d14b
/external/okhttp/android/main/java/com/squareup/okhttp/HttpHandler.java
|
| ae4b4a66e778b557d67f34f75009200e4eec34a9 |
|
09-Dec-2015 |
Chad Brubaker <cbrubaker@google.com> |
Merge "Refactor NetworkSecurityPolicy to be pluggable"
|
| a8b361812f24441b359e797416e1251e2662f1c3 |
|
08-Dec-2015 |
Chad Brubaker <cbrubaker@google.com> |
Refactor NetworkSecurityPolicy to be pluggable
This allows us to keep the logic for the NetworkSecurityPolicy in the
framework instead of in libcore.
Change-Id: I4bf494f79c27729cb17d93d90a91319492270ce9
/external/okhttp/android/main/java/com/squareup/okhttp/HttpHandler.java
|
| b701c07a57f6c8a871ed7a56860c6d0452bd740d |
|
30-Nov-2015 |
Neil Fuller <nfuller@google.com> |
Fix HttpURLConnection.setFollowRedirects()
OkHttp's HttpURLConnectionImpl stopped using the static value set
on HttpURLConnection directly with commit
e78f117bcbd6b57d783737107f445ef75ecb474a
and started expecting a new value on OkHttpClient to be set
instead. This means that HttpURLConnection stopped obeying
the HttpURLConnection static setting. This change adds the necessary
behavior back.
Bug: https://code.google.com/p/android/issues/detail?id=194495
Bug: 25928343
Change-Id: Ic808f94056d1932f35e8f72746be8362452797db
/external/okhttp/android/main/java/com/squareup/okhttp/HttpHandler.java
|
| f4a606d2680805b15b1908c0fbb3ef0a0f90bac1 |
|
29-Jun-2015 |
Neil Fuller <nfuller@google.com> |
Explicitly set Http(s)URLConnection timeouts
The defaults are changing upstream with change
https://github.com/square/okhttp/commit/0de14e992c228fd9de9fe78417788131bee00902
to 10 seconds.
If the timeouts are not set explicitly the behavior will change
next time Android pulls from upstream.
Change-Id: I3702f2a98fbcb547518e50574a504ebd9e81bf68
/external/okhttp/android/main/java/com/squareup/okhttp/HttpHandler.java
|
| d216739b44b542171c404422f70d38a822571269 |
|
21-Mar-2015 |
Alex Klyubin <klyubin@google.com> |
Honor NetworkSecurityPolicy regarding cleartext traffic.
This makes okhttp's Android URLStreamHandler instances honor the
process-wide policy about cleartext network traffic. If cleartext
network traffic is not permitted, then attempts to open okhttp-backed
URLConnections will throw an IOException.
Cleartext HTTP attempts violating the policy will now result in
URLConnection throwing a java.net.SocketException complaining that no
route to the host could be found because no connection specs are
available. The message or the exception type could be improved upon
for easier troubleshooting. However, this is how okhttp decided to
handle this policy for now. We could intercept connection attempts
earlier, and throw our own exception, but it's not clear how much
benefit this additional complexity will provider.
Bug: 19215516
Change-Id: I38afc86eeee8b1c237e9ae45c4ca884dc7310152
/external/okhttp/android/main/java/com/squareup/okhttp/HttpHandler.java
|
| 2ab4219879241a2d3b45eb5c6a504b51fad101e8 |
|
21-Jan-2015 |
Neil Fuller <nfuller@google.com> |
Tidy up HttpsHandler / HttpHandler and change defaults
OkHttp was recently upgraded in AOSP. This is a tidy
up change to correct some defaults and improve documentation
of Android settings.
Besides better docs this change mostly focuses on
ConnectionSpecs.
OkHttp now has a set of default ConnectionSpecs. ConnectionSpecs
control TLS version and cipher suite selection during connection
negotiations.
The defaults are not what we want on Android:
Historically, it looks like we don't want HttpsURLConnection
being redirected to http:// addresses, and HttpURLConnections
being redirected to https://. This means that we can
exclude any TLS-based ConnectionSpecs from HttpHandler, and
cleartext-based ConnectionSpecs from HttpsHandler making that
choice even more explicit.
TLS versions:
The upgrade effectively had a side-effect of disabling SSLv3
in all cases. On Android we disable SSLv3 in the default socket
factory (getEnabledProtocols()), but it is still supported on
the socket (getSupportedProtocols()).
In the L release, OkHttp would use the default TLS versions
for the initial connection and SSLv3 only for the fallback
(i.e. with the default socket factory it would turn it back on
for the fallback connection).
This change allows for applications that may need to use SSLv3.
SSLv3 will only be used if there is an installed socket factory
that enables it by default.
There should be a future change coming to upstream that will
further alter this behavior because OkHttp will still make
multiple attempts to connect when it knows it won't work.
Ciphers:
OkHttp is opinionated about the cipher suites to enable
on a socket. On Android, we want the SocketFactory to determine
the set of acceptable ciphers and we should just use the default
enabled set (because the default set may be better than the
set known when the device shipped, e.g. the socket factory may
come from GMS or installed by an app and therefore provide better
ciphers or disable ones that have found to be broken).
This change fixes two failing tests in
libcore.java.net.URLConnectionTest due to the TLS version
changes.
Change-Id: Iefc77746695b307a1222faf336d9d6452e974810
/external/okhttp/android/main/java/com/squareup/okhttp/HttpHandler.java
|
| e78f117bcbd6b57d783737107f445ef75ecb474a |
|
20-Jan-2015 |
Neil Fuller <nfuller@google.com> |
Pull latest OkHttp code from upstream
okio:
okio is now managed upstream as a separate project but has
been included here as a sub directory: the okio version here
is intended only for use with OkHttp.
okio is synced to upstream commit
82358df7f09e18aa42348836c614212085bbf045.
See okio/README.android for local changed needed to make it
compile.
okhttp:
This is effectively an upgrade from a snapshot close to
OkHttp 1.5 with Android additions to a snapshot close to
OkHttp 2.2.
okhttp was synced to upstream commit
0a197466608681593cc9be9487965a0b1d5c244c
See README.android for local changes needed to make it
compile.
Most of the old Android changes have been pushed upstream
and other upstream changes have been made to keep OkHttp
working on Android.
TLS fallback changes have not been upstreamed yet:
bcce0a3d26d66d33beb742ae2adddb3b7db5ad08
ede2bf1af0917482da8ccb7b048130592034253d
This means that some CTS tests will start to fail. A later
commit will fix those changes when it has been accepted
upstream.
There are associated changes in libcore and frameworks/base.
Change-Id: I0a68b27b1ec7067be452671bc591edfd84e310f2
/external/okhttp/android/main/java/com/squareup/okhttp/HttpHandler.java
|
| 8bced3e769d315a0a81b89de7a5282f1a85acbf7 |
|
11-Sep-2014 |
Neil Fuller <nfuller@google.com> |
Alter Android's connection pool behavior on network config changes
Rather than clearing out and closing the shared connection pool
each time the network changes with evictAll() this ensures that
later Http(s)URLConnections will reference a new ConnectionPool
instance.
This is an improvement over the current implementation:
1) It is obviously non-blocking.
2) It ensures that connections for the old network config
and are currently in use are not put back into the shared
pool.
Change-Id: I7b62f2bbd306c932dfd8d0ff4fff236ec04405bf
Bug: 17314604
/external/okhttp/android/main/java/com/squareup/okhttp/HttpHandler.java
|
| 84f674f3abba1083e1efd94520d516036a3f0b6a |
|
03-Sep-2014 |
Neil Fuller <nfuller@google.com> |
external/okhttp changes to support connection pool flushing
When the preferred network / default network for a device
changes we must flush any pooled connections.
This change has a known issue which will be fixed in a
later commit: Any connections that are in use when
the pool is cleared can be put (back) into the pool after
evictAll(). This means those connections will continue to
reference the old preferred / default network.
Bug: 17314604
Change-Id: Icbe20db77922cdbe1d6965785de7ee59495044de
/external/okhttp/android/main/java/com/squareup/okhttp/HttpHandler.java
|
| c19427fc6c8c1be67970437643c8fe90e328fc6c |
|
09-Sep-2014 |
Neil Fuller <nfuller@google.com> |
Enable android.net to reuse OkHttpClient creation logic
Pulling out static factory methods from HttpHandler and
HttpsHandler. android.net will call these to create
OkHttpClient instances which they can then further tweak
for their own purposes.
Bug: 17420465
Change-Id: Ib22e79ee3a2fec343dbf518d6f885b18997b0002
/external/okhttp/android/main/java/com/squareup/okhttp/HttpHandler.java
|
| 3c938a3f6b61ce5e2dba0d039b03fe73b89fd26c |
|
19-Feb-2014 |
Neil Fuller <nfuller@google.com> |
Update okhttp to a more recent commit.
Updating to upstream commit : 7b106923e078ac2435e8c8ce9d615f9903106ed8
/ 7th Mar 2014 / main branch.
The following changes were made to Android-only code:
1) HttpsHandler has been changed to deal with the fix for:
https://github.com/square/okhttp/issues/184 (commit 5d7fdba).
2) Platform.java changed to accomodate changes in okhttp Platform
method signatures.
3) .mk file updates to reflect src directory changes.
The following changes were made to OkHttp code:
1) Removal of org.codehaus.mojo.animal_sniffer.IgnoreJRERequirement
annotation from okio/src/main/java/okio/DeflaterSink.java
Change-Id: I644a883482ac7ee7d029785f110a2ca00762419b
/external/okhttp/android/main/java/com/squareup/okhttp/HttpHandler.java
|
| bf0942e19906b85a3a061d1e762a4474bef6f1e2 |
|
13-Jun-2013 |
Narayan Kamath <narayan@google.com> |
Don't follow protocol redirects.
OkHttp allows protocol redirects by default, so turn them
off explicitly.
Also, let HttpsHandler extend HttpHandler so that they can
share code that deals with OkHttpClient initialization.
Change-Id: I890456260571abd40a64ab1647eb4e991f5b1c7e
/external/okhttp/android/main/java/com/squareup/okhttp/HttpHandler.java
|
| 2231db3e6bb54447a9b14cf004a6cb03c373651c |
|
26-Dec-2012 |
jwilson <jwilson@squareup.com> |
Upgrade to the latest OkHttp.
Note the internal package name has changed from libcore.net.http
to com.squareup.okhttp.
Change-Id: Ib0eb4bdd69f24f2a255975460bd001e59657ddcc
/external/okhttp/android/main/java/com/squareup/okhttp/HttpHandler.java
|