* (in-progress) Support gzipped bodies as a networkInterceptor
* Fixed buffer cloning, added test for a still-unsupported encoding (Brotli)
* Avoid try-with-resources and too-long lines to appease build checks
* Fixed method name typo
* Added suggested comma between byte and gzipped-byte count
* Account for added comma in test
* Use buffer.writeAll to ensure all body content is read
* Indentation consistency
* Added test to confirm response body remains valid
As-is it throws unchecked exceptions on unexpected charsets. This is a problem
because it can cause a misbehaving webserver to crash the client.
I don't expect this to break existing clients; returning 'null' has always
been a possibility; it's just returned in more cases.
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
Still some work to do on method naming, but this was the interesting part.
Also very much need to rename OkUrlFactory in tests to urlFactory, otherwise
the client.client stuff becomes madness.
Instead each new instance of OkHttpClient gets its own connection pool by
default. This makes the OkHttpClient instances a little more heavyweight
(in that two different instances yield two different connection pools, which
means two different cleanup threads) but it also means there's less weird
state sharing between instances.
One drawback of this is that if an application wants to immediately free
resources from an OkHttpClient it must call getConnectionPool().evictAll(),
otherwise the connection pool thread will remain alive for 5 minutes.
