To build HTTP/2.0 support into OkHttp I'm going to simultaneously
build HTTP/2.0 support into MockWebServer. To make that possible,
I'm first going to fork MockWebServer and then combine it with
MockSpdyServer.
With spdy/3 the built-in headers were renamed from 'status'
to ':status' and 'version' to ':version'. This caused the
response cache to break, since it was parsing lines like
':status: 200 OK' by splitting on the first colon.
The fix drops these synthetic headers as soon as they're
received; converting them to the HTTP form immediately.
These are only turned on for non-GET requests. This
replaces the RetryableOutputStream mechanism, which
was causing problems for clients whose POSTs weren't
idempotent.
The documentation for org.apache.http.HttpEntity::getContentLength()
states that a negative number will be returned when the length of the
content is not known.
The SPDY protocol states the sender of FLAG_FIN must not send further frames
on that stream. This change skips the sending of a final (empty) frame with
FLAG_FIN set when the stream is already half-closed because SYN_STREAM was
sent with FLAG_FIN set.
This breaks the direct dependency from HttpEngine to
HttpURLConnectionImpl. With this dependency broken, we
can start to use HttpEngine directly from Dispatcher and
Job.
We aren't going to use HttpURLConnectionImpl for
requests with the new API.
This is safe because we always do a shallow copy of
the OkHttpClient before using it to create a
HttpURLConnectionImpl.
This allows us and our users to parse out the charset of
a content type, so we can cleanly create Readers and Strings
for content of any type.
This is similar to Guava's MediaType but with many differences.
* Guava's MediaType parses all parameters independently. We don't.
We may later want to support this lazily for users like MimeCraft.
* Guava uses a custom Tokenizer; we use regular expressions.
* Guava includes a registry of common media types; we don't.
* Guava supports media queries and building media types; we don't.
Applications that need advanced features should probably use
Guava's MediaType class. My goal here was to get everything we
need in a small amount of code.
This is very experimental right now but it sets us up
for a full asynchronous API. The current implementation
builds an async API over our existing synchronous API.
Future refactorings to the internals should promote the
async API throughout the codebase, particularly in SPDY.
That way we can have more requests in flight than threads
processing those requests.
