This interface was necessary while cleaning up the delicate
intertwined relationship between HttpURLConnection and HttpEngine.
With this change HttpEngine no longer has a reverse dependency
on HttpURLConnection.
Move gateway timeout failures to CacheStrategy, and inline
methods nearby for a strict top-to-bottom flow in this method.
It becomes more obvious that the end of sendRequest has two
cases: we need a connection (opening if necessary) or we don't
need a connection (closing if necessary). Previously this was
true but not as explicit.
This renames ResponseStrategy to CacheStrategy and cleans up
the code that calls into it.
This fixes a bug where we were incorrectly reporting stats
when the caller was requesting only-if-cached. In those cases
we were tracking stats before applying that constraint. Tests
for these cases have been added
Now that Request and Response self-describe, I think the
word Headers is sufficient. And it's a lot less ugly than
RawHeaders.
Also move header serialization code to HttpTransport and
SpdyTransport.
Policy is a bridge to get us from a place where HttpEngine
depends 100% on HttpURLConnection to a place where it
doesn't.
We've refactored the code in HttpEngine enough now that
some Policy methods are no longer necessary. Delete 'em.
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.
