We were only returning 'true' once we were already in a tunnel.
This was bogus. In theory a TLS tunnel sending extra data could
be corrupted due to this bug.
Also migrate one of the TLS tunnel tests to use SslContextBuilder
instead of TestSSLContext.
Original AOSP/libcore commit from Vladimir Marko:
Add StrictLineReader for efficient reading of lines
consistent with Streams.readAsciiLine(). Use this to improve
DiskLruCache.readJournal() and initialization of
HttpResponseCache$Entry from InputStream.
(cherry-pick of e03b551079aae1204e505f1dc24f2b986ef82ec0.)
Bug: 6739304
Change-Id: If3083031f1368a9bbbd405c91553d7a205fd4e39
Original AOSP/libcore commit by Brian Carlstrom:
java.lang.Throwable: Explicit termination method 'end' not called
at dalvik.system.CloseGuard.open(CloseGuard.java:184)
at java.util.zip.Inflater.<init>(Inflater.java:82)
at java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:96)
at java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:81)
at libcore.net.http.HttpEngine.initContentStream(HttpEngine.java:523)
at libcore.net.http.HttpEngine.readResponse(HttpEngine.java:831)
at libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:274)
at libcore.net.http.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:486)
at ...
Bug: 6602529
Change-Id: I9b49cbca561f8780d08844e566820087fdffc4d7
Original AOSP/libcore commit from Brian Carlstrom:
This fixes an issue where a bad proxy repsonse that included a body
would turn into an IllegalStateException instead of an IOException.
Bug: 6754912
Change-Id: I204ad975820693d6add2780d7b77360463e33710
This is more lenient than necessary; the HTTP spec says this:
10.4.2 401 Unauthorized
The request requires user authentication. The response MUST include a
WWW-Authenticate header field (section 14.47) containing a challenge
applicable to the requested resource.
Not throwing will still cause the request to fail, since the 401
response code triggers an IOException. But this type of failure is
more recoverable and allows the caller to inspect the headers and
response body.
This makes a bunch of sad changes for compatibility:
- Using String.length() rather than String.isEmpty()
- Using String.getBytes(String) rather than String.getBytes(Charset)
- Using new String(..., String) rather than new String(..., Charset)
- Avoiding TimeUnit.DAYS
I've tested this and the HTTP tests run perfectly fine on Froyo.
The HTTPS tests time out due to a bug in Froyo that prevents
its TLS library from working as a server. I manually verified
that TLS works as a client without problem.
I also tested this on Gingerbread. It passes all tests except
for testConnectViaHttpProxyToHttpsUsingProxySystemProperty, which
fails because of a bug in Gingerbread's java.net.ProxySelector.
This change introduces caching reflective objects for NPN access.
That'll make clients that make multiple SSL connections slightly
more efficient.
Because there are no platform APIs to generate certificates,
this needs a third party library (bouncy castle) to do the
heavy lifting.
Each target platform has its own built-in crypto library:
- The JVM has its own internal crypto library. It uses
key stores like "JCA".
- Android has its own internal crypto library that's
based on bouncy castle. It is repackaged in com.android
and is not used by this code.
With this change, okhttp brings its own copy of bouncy castle
for cert generation. Once the certificate is generated we're
done with bouncy castle, and use the platform libraries for TLS.
This approach allows us to use one codebase on either platform.
This is a fork of okhttp from http://code.google.com/p/okhttp.
I'm moving it to Github since that's where my code reviewers
are. I've renamed the core package from com.google.okhttp to
com.squareup.okhttp because Square is where I expect ongoing
development of this project to take place.
All code in this project is subject to be contributed upstream
to AOSP. In particular, all code in the libcore package is
derived from AOSP and intended to be contributed back to AOSP
on an ongoing basis.
