diff options
| author | Tobias Thierer <tobiast@google.com> | 2016-06-02 14:35:36 +0100 |
|---|---|---|
| committer | Tobias Thierer <tobiast@google.com> | 2016-06-29 17:40:54 +0100 |
| commit | 321eed87d5dc289ea7c212c2fb743f57cc8d5b15 (patch) | |
| tree | 831599aa2ebb28d03f26c770b3b5bdba29acbde8 /include/ScopedJavaUnicodeString.h | |
| parent | 08d3979a5fab6f8a18a70807026f54793d20d186 (diff) | |
URLConnectionTest changes for upgrade to OkHttp 2.7.5
These changes are required due to behavioral changes between OkHttp
2.5 and 2.7.5 which we want to accept for AOSP.
- ProxySelectors now get a URL reconstructed from an Address (without
path, query parameters and fragment) rather than the full request
URL. Proxy selection should not usually depend on those values:
DefaultProxySelector cannot be configured to do so;
PacProxySelector probably can be but it'd be a hack. In the absence
of evidence that a significant number of clients rely on such a
hack, we don't want to try to continue to support such behavior.
This behavioral change affects testRedirectWithInvalidUrl() and was
introduced by:
github.com/square/okhttp/commit/c358656c8799d30fd422448153e99a5dd37e298a
which no converts the URL to an Address, then back to a URL that's
delivered to the proxy selector.
- When clients set a Proxy-Authorization header on a request to a
target server (e.g. google.com), previous versions of OkHttp would
have copied that header to the request to the proxy that
established a tunnel. It's unreasonable to support clients that may
rely on this hack because this leaks the Proxy-Authorization header
to the target server. Instead, the Proxy-Authorization header is no
generated on the library level in response to a HTTP 407 Proxy
authentication required status, which requires an additional round
trip.
Similarly, the request to the proxy to set up the tunnel used to
have the User-Agent copied from the initial tunneled request.
Instead, this request's User-Agent is now generated at the library
level through Version.userAgent()
- OkHttp 2.7 has new logic for CertificatePinning that we do not
want to expose through Android's API surface; Android already
has a different implementation of certificate pinning. This CL
adds a sanity check that some Platform logic that OkHttp 2.7.5
uses only for certificate pinning is not invoked in the common
case of Http{s}URLConnections.
More details on these and other changes that didn't affect tests, at:
https://docs.google.com/document/d/19PF3Exd_q32gAGCiRFWRf0Pq_xrIWs-cRViHkFTxJg8/edit
Change-Id: I29277aea0beb8921b3038fefb922b669e01bf106
Diffstat (limited to 'include/ScopedJavaUnicodeString.h')
0 files changed, 0 insertions, 0 deletions
