This is a binary-compatible change, but code that currently calls
RequestBody.contentLength() doesn't necessarily catch or declare
IOException, and will need to with this change.
MultipartBuilder is most impacted by this change; previously the
length was computed eagerly; now it's not computed at all.
Applications that require the previous behavior should fully
buffer the request bodies and use that to compute the length.
Closes https://github.com/square/okhttp/issues/1141
This was present in a bunch of loops, but not all and not consistently. After fixing two, I figured that I would normalize them all under the umbrella of uniformity and being lazy (only lookup up the value once if it never changes).
Work in progress.
I see a new failure from a certificate pinning test but I don't
know why. Help solving this would be appreciated.
I also see failures before & after:
1) A failure from DisconnectTest
(https://github.com/square/okhttp/pull/1197 may fix that).
2) A failure from CallTest.doesNotFollow21Redirects_Async (timeout)
The maven changes should be treated with the contempt they deserve.
I mostly removed things I didn't understand and stroked maven until
it stopped squealing. The benchmarks / okcurl changes are a
particular mystery.
Tried with arbitrary versions of openjdk7 and openjdk8 I had
lying around. Behavior was the same across both (i.e. the same
failures).
Compelling alternative is ReadableBody and WritableBody, or BodySource and BodySink.
Which in theory permits reuse for serverside body makers. But I don't like those names
as much.
The status line is an unnecessary grouping of three otherwise-independent
fields: the protocol, code and message.
Combining them in the API doesn't provide much value. In SPDY and HTTP/2
these are broken apart anyway.
Drop setTransports/getTransports which was deprecated in favor
of protocols.
Rename setFollowProtocolRedirects to setFollowSslRedirects. I decided
to use SSL rather than TLS for consistency with nearby APIs.
