The API is imperfect because HttpURLConnection doesn't expose
any SSL information, and because HttpsURLConnection won't necessarily
have a secure final request.
Previously it was acting as both the user's requested proxy and
also the proxy selector's selection. This breaks down, especially
since redirects permit multiple proxy selections for a single
request.
We were missing out on opportunities to reuse HTTPS connections
with the previous timeout. This even occured on unit tests where
the latency should be very low.
https://github.com/square/okhttp/issues/90
Original AOSP/libcore commit from Brian Carlstrom:
We need to strip both the Content-Length and the Content-Encoding
for such requests. In such requests, it will be the length of the
compressed response. We hide the fact that compression is taking place
from clients, so we shouldn't give them the content length either.
Change-Id: I80713ab33143945c5e2656f478d83cc9e60226a8
Writing tests shook out a few bugs:
- Pooling wasn't working well. We were trying to connect
after already having been connected.
- We weren't writing response bodies to the cache.
- We weren't capturing the request time for the cache.
- MockSpdyServer wasn't trimming headers.
New files in this change aren't new, they're just inner classes promoted
to top-level classes for better sharing.
This is like MockWebServer, but it speaks SPDY behind the scenes
instead of HTTP. The goal with this change is to make it very easy
to test interactions between SPDY and HTTP features like cookies,
fault tolerance and caching.
This adds a first test where a frame is truncated. That has some
unpleasant consequences for the other tests because it means the
MockSpdyPeer is more aggressive about closing the socket when all
frames have been sent.
It also reduces the use of exceptions for flow control when handling
bogus incoming frames. This is a bit worse and a bit better; my
goal is to make it easier to differentiate between protocol-level
problems (bogus frames) from transport-level problems (closed sockets
and EOF streams).
We had a bug where we were using spdy/2's layout for
setting frames rather than spdy/3's layout. I discovered
this when testing flow control against Chrome.
This fixes uploads greater than 64 KiB.
This sends a WINDOW_UPDATE frame whenever the total number of
unacknowledged bytes exceeds 32 KiB. This is a simple policy;
we could tune it to be more sophisticated as necessary.
This fixes downloads of streams greater than 64 KiB.
