This doesn't completely support ISO-8859-1 headers; instead they will most likely
be mangled when they are decoded as UTF-8. If we decide we absolutely must support
ISO-8859-1 here we can do that in another change. (I'm not currently enthusiastic
about this idea.)
But this does prevent OkHttp from crashing when it encounters non-ASCII characters
in headers for HTTP/2, SPDY, and cached responses.
Closes: https://github.com/square/okhttp/issues/1998
This change also fixes an edge case where a server returns a response
that allows a follow up request. Previously, this would cause an
exception because the body was being ignored.
This implements the following policy:
- If a REFUSED_STREAM error is received, OkHttp will retry the same stream
on the same socket 1x.
- If any other error is received, or an additional REFUSED_STREAM error is
received, OkHttp will retry on a different route if one exists.
We may want to follow up by going through HTTP/2 error codes and deciding
a per-code retry policy, but this should be good enough for now.
Closes: https://github.com/square/okhttp/issues/2543
Otherwise we can deadlock, with OkHttp waiting for the server to send a larger
window and the server not knowing that there's a stream that even wants it.
The previous approach Just Works if users have fancy or interesting interceptors
that genuinely need to swap the response body in an interceptor and keep the
original body.
One problem with that solution is that although it gives expert users a powerful
way to separate response bodies, it also allows normal users to accidentally leak
response bodies in their interceptors.
This is an alternate solution that forbids the expert use case and requires that
closing the response body stream also closes the underlying socket stream. It
throws an exception if that implicit contract is not honored.
I'm fine with either solution but think we should consider both.
I'm currently keeping these as longs. That's easy an unambiguous, but it also
feels rather primitive.
This was more work than I expected, but it doesn't seem particularly risky.
It's also potentially more efficient, since there's fewer places where we're
converting from string to long and vice versa.
Closes: https://github.com/square/okhttp/issues/2035
Avoid using System.out.
Use the best logging implementation on the host platform. On Java this is
java.util.logging. On Android it's Android.util.Log.
Closes https://github.com/square/okhttp/issues/2505
