The request line is now standalone because it depends
on the proxy (for full URL or not) and the connection
(for HTTP version). I may change this later and put
this info in the request.
The status line now moves into Response. I have a
helper class StatusLine that does the parsing. I may
later want to hide this or make it public; I'm not
quite sure yet!
The net result is that RawHeaders is getting dumber
and used in fewer places, which is good news. This
change also shows nice simplifications to the
authenticator (which needs fewer args) and to the
tunnel builder.
Also fold together HttpsEngine and HttpEngine; the
HTTPS subclass wasn't pulling its weight.
This cleans up a lot of the unnecessary moving parts in
HttpEngine. That class is still stuck with some complexity
around request and response bodies, but it's getting better.
We're also stuck escalating the visibility of a lot of
members in Request and Response. I've got some ideas on
how to fix this; that'll have to wait for a follow up.
This introduces a new, poorly-named class ResponseStrategy
that pulls some code out of ResponseHeaders. That was necessary
because the old method mutated itself and its parameters in
place.
Obvious follow-up for this is to combine ResponseHeaders with
Response, and RequestHeaders with Response.
This breaks support for java.net.ResponseCache implementations. That's
good. That API is akward and can't support important features like
conditional GETs and hit tracking.
I needed a non-terrible way to provide the HTTPS handshake
information to the async API. Previously we were passing the
live socket around, which was leaky and gross.
This creates a new value object that captures the relevant
bits of the handshake. We can use it in the response, the
connection, and also in the cache. It's plausible that in
the future we can use it to allow the application to block
requests if the handshake is insufficient.
Using HttpEngine directly introduces some duplicated code with
HttpURLConnection. It also breaks the response cache. I think
this is the best route going forward; and eventually we could
invert this relationship to have HttpURLConnection depending on
Job directly rather than vice versa.
This notably allows the mockwebserver project to be run on Android.
ServerSocket only implements Closeable since Java 1.7 and thus calling of
closeQuietly(Closeable) with a ServerSocket argument fails when running
on Java 1.5 or 1.6 JVMs. This is the same as is already done for
closeQuietly(Socket).
This was causing some SPDY connections to be evicted early,
and preventing connection reuse.
The spdyConnectionReuse test becomes flaky with the
fix that makes MockWebServer use different sequenceNumbers
for different requests on the same socket. With the fix
the test is no longer flaky. The old test wasn't good enough
to detect what it wanted to detect!
This race has existed in the code since we added more
aggressive time-based expiration in January 2013. In my
basic tests the race impacted ~20% of connections on a
desktop VM. It may have been more on mobile.
