This means we'll cache responses that use an 'Authorization' header. This
means OkHttp's cache shouldn't be used on middleboxes that sit between
user agents and the origin server; in practice this is never a use case
for OkHttp.
Fixes https://github.com/square/okhttp/issues/1035
When streaming a response, we copy data from our buffer to the cached file
on disk. Unfortunately we were copying N bytes from the front of the buffer
when we wanted N bytes from the back of the buffer.
Typically these are the same, but certain access patterns can cause them
to be different, corrpting the cached file on disk.
This was uncovered by migrating the cache tests from operating on
HttpURLConnection's API to our new API.
The HttpEngine would not obey the set state because there was no
correlation between the HttpURLConnection.setInstanceFollowRedirects
method and the OkHttpClient.
Fixed the missing link by adding a new setFollowRedirects method to the
OkHttpClient class. Bridged the gap for the HttpURLConnection.setInstanceFollowRedirects
by forwarding that state into the OkHttpClient.
Now the HttpEngine will always obey the OkHttpClient redirect state when
attempting the followUp phase.
Added necessary test to both OkUrlFactoryTest and CallTest.
https://github.com/square/okhttp/issues/943
These are potentially private and we don't want to leak them to another
host, regardless of whether they're created by the calling application or
by the Authenticator.
This extracts the URLConnection APIs to their own project. I still need to
go back and clean up some names in tests, add documentation, and move the
actual HttpURLConnection implementation details into this module.