* Use try-with-resources
* Make bodyHasUnknownEncoding() static
* Fix nits in HttpLoggingInterceptorTest
* Revert "Use try-with-resources"
This reverts commit 57dcd61a9e.
* Add LoggingEventListener and use it in okcurl
* Fix tests failing in IP6 environment
* Make less assumptions about test environment
* Disable retry in test to make test sequence more predictable
* Fix javadoc compilation
There seems to be inconsistency between javdoc parsing between 'mvn verify' and Travis CI. Before the change, 'mvn clean verify' passes but Travis CI fails due to missing import of okhttp3.OkHttpClient. Just adding the missing import, causes 'mvn verify' to fail die to unused import. Changing the line wrapping seems to appease 'mvn verify'.
* Address comments
* Remove unused imports
* (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.
