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.
We can't use the regular socket timeouts because the
socket is shared. Moving it to the application level
is more complicated, but it allows different streams
to set timeouts independently.
This avoids a memory leak; we don't hold onto the input stream
and it's large 64 KiB buffer long after that stream is done.
It also allows SpdyConnection to track how many streams are
currently active. This will allow a follow up change to shut
down connections that don't host any streams.
This moves methods that will have Android-specific implementations
to Platform.java; all other utility methods are in a junk drawer
class called Utils.java.
This also moves method names (like "GET") to compare with .equals
instead of '=='. The old code took advantage of a hidden agreement
between HttpURLConnection and HttpEngine; with these in separate
projects that behavior isn't as obvious and shouldn't be relied
upon.
Giving the application code access to the connection pool
is tricky: it exposes more implementation details from
OkHttp; details that are quite inaccessible through the
conventional HttpURLConnection APIs. Currently the only
thing regular users get are a pair of awkward system
properties.
But exposing these should also be useful: it'll allow the
application to observe the pool (for performance monitoring)
and possibly also to directly manage it (by setting policy,
or to evict when the application is paused).
One of the test cases bitrotted to failure as a consequence
of the HTTP route selector change. I stopped assigning the
socket, which it needed to cache the TLS metadata. This is
fixed.
