ResponseBody.create(MediaType, String) constructs an object which can be mutated into an invalid state using ResponseBody.string()

Basically we bumped into this when writing unit tests to our component which uses Retrofit and therefore OkHttp. The version of OkHttp is 2.5.0.

When you construct an object using the ResponseBody.create(MediaType, String), two subsequent calls to ResponseBody.string() will fail with an IOException so the getter seems to mutate the object and mutates it to corrupted state. The behaviour is not indicated by the javadoc of ResponseBody.string() and therefore it was a surprise and we did spend for a while wondering what’s the problem here. RealResponseBody does not seem to be affected by the same issue.

To reproduce the problem:

    @Test
    public void testResponseBodyCreate() throws IOException {
        ResponseBody body = ResponseBody.create(MediaType.parse("text/plain"), "test");

        body.string();
        body.string(); // Fails with IOException when using okhttp 2.5.0
    }

Which reports

java.io.IOException: Content-Length and stream length disagree
    at com.squareup.okhttp.ResponseBody.bytes(ResponseBody.java:62)
    at com.squareup.okhttp.ResponseBody.string(ResponseBody.java:83)

This probably should be documented in the javadocs or the behaviour should be fixed.

[JakeWharton]

Every ResponseBody instance can only be read once, in practice, as there’s no automatic buffering happening. string() is effectively an exhaustive read of the input so on a subsequent call the underlying data source is empty (hence the exception message).

[JakeWharton]

Application code should cache the response themselves or replace the RequestBody instance when consuming the stream.

On Wed, Nov 11, 2015, 3:18 AM mkatsoho [e-mail] wrote:

Just a suggestion. Can refer to the similar function in rest-assured, it is idempotent. I guess it cached the http resp body, and return it in later calls.

— Reply to this email directly or view it on GitHub https://github.com/square/okhttp/issues/1968#issuecomment-155701090.