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.
There were some tests that only work on Dalvik/Linux: the CloseGuard
test and the timeout test rely on Linux-specific behavior that's too
flaky for a general test.
The TrustManager test just needed some attention and simplification to
work on both the JDK and Dalvik TLS stacks.
This makes it possible to have two HttpClient instances that
don't share cookies or response cache policy. For example, a
program that makes both REST calls and downloads images may
prefer different response caches for each type of resource.
The builder has two upsides:
- It allows us to use the same base classes from java.net
as the base API.
- It gives us a place to stash configuration in a place other
than static fields. This will be useful for the connection
pool, cookie manager, response cache, etc.
