This fixes a break caused by the recent try-harder-on-IP-addresses
change, where if the first connect failed we returned rather than
trying until we reached a connection or an error.
I was trying to reproduce a connectivity problem and
I found other related problems along the way:
- We were unnecessarily creating new HttpConnection instances.
- We were using "" as the file instead of "/" for SPDY.
Previously the returned connections required the caller to
do extra work: setting up tunnels (which could require auth)
and performing an SSL handshake. With this change we make a
complete working connection in HttpConnection.connect().
This will make it easier to fix fallback when a single domain
has multiple IP addresses and some of those addresses are not
reachable.
This will also make it easier to do SPDY through HTTP proxies.
We had a bug where the underlying SSLInputStream always returned
0 for InputStream.available(). This prevented us from ever reading
the "end of stream" chunk, which prevented connection recycling.
http://code.google.com/p/android/issues/detail?id=38817
Also fix a nearby bug where we were fast-forwarding the gzipped
stream when we should have been fast-forwarding the transfer
stream when we were preparing to recycle a connection.
Writing this change has led me to believe that the
concurrency here is just plain awful, and I need to
find a better solution than what I have. In particular,
there are too many threads:
- the internal reader thread
- application reader threads
- application writer threads
And too many locks:
- the SpdyWriter I/O write lock
- the SpdyConnection internal state lock
- each SpdyStream's internal state lock
What's currently very wrong is the internal reader thread
is updating state in the SpdyStream, and reading bytes from
the network into a particular stream. It is an error to hold
the SpdyStream's lock while reading, but we're doing it because
we need to hold the state on the buffer, position and limit.
We need to rethink this!
Chrome doesn't run into this problem because it can 'fire and
forget' events. We can't do that because SPDY writes need to
throw IOExceptions if the writes fail.
Although blocking calls don't fit the SPDY model very well, they
make exception transparency easy. In this case, a NOOP or a PING
will throw if it cannot be sent. This is good.
The current status line parsing is lenient and sloppy; a
holdover from an ancient version of this library. The new
code is strict and provides a helpful message if a bogus
status line is encountered.
To make this possible the RawHeaders class needs a hint
about whether it's looking for a request line (from an
HTTP request) or a status line (from an HTTP response).
The old sloppy code used the same APIs for both.
Setting fields and then calling a method is just not as usable
as calling a method that takes arguments.
Also move Settings into their own class, so we can sling them
around without a bunch of ceremony.
SpdyConnection needs to guard its own state separately from
the SpdyWriter, which permits slow blocking calls. Split these
into multiple independent locks.
Also use independent right-sized thread pools for reading (exactly
one thread all the time) delayed writing (0 or 1 threads) and
callbacks (any number of threads).
Though it isn't particularly useful in practice, it's
going to be extremely handy for testing since it makes
a happens-before relationship very easy to create.
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.
