Okhttp: BufferedSource.readUtf8() causing DataFormatException: invalid distance too far back

[ppamorim]

After I updated OkHttp to 4.8.0, I started receiving this error in the crash reporting tool.

Stack trace:

Non-fatal Exception: java.io.IOException: java.util.zip.DataFormatException: invalid distance too far back
       at okio.InflaterSource.readOrInflate(InflaterSource.java:99)
       at okio.InflaterSource.read(InflaterSource.java:49)
       at okio.GzipSource.read(GzipSource.java:69)
       at okio.internal.BufferKt.commonWriteAll(BufferKt.java:1061)
       at okio.Buffer.writeAll(Buffer.java:1655)
       at okio.internal.RealBufferedSourceKt.commonReadUtf8(RealBufferedSourceKt.java:171)
       at okio.RealBufferedSource.readUtf8(RealBufferedSource.java:309)
       ...
       at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:423)
       at java.util.concurrent.FutureTask.run(FutureTask.java:237)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
       at java.lang.Thread.run(Thread.java:818)

Example:

inline fun run(result: (Int, BufferedSource) -> Unit) {

    val json = JSONObject()
    json.put("foo", 123)
    val requestBody = json.toString().toRequestBody(JSON)

    val request = Request
        .Builder()
        .url("https://google.com")
        .post(requestBody)
        .build()

    val response = okHttp
        .newCall(request)
        .execute()

    response.body?.run {
        if (response.isSuccessful) {
            result(response.code, source())
        }
        close()
    }

}

And then:

run { _: Int, bufferedSource: BufferedSource ->
    val result = bufferedSource.readUtf8() //Crash here
}

Could be source() and then calling readUtf8() be the problem?
The crash happened in a Galaxy Grand Prime Plus running Android 6.0.1.

Secondary log crash report (can be related):

Non-fatal Exception: java.io.IOException: ID1ID2: actual 0x00000800 != expected 0x00001f8b
       at okio.GzipSource.checkEqual(GzipSource.java:197)
       at okio.GzipSource.consumeHeader(GzipSource.java:110)
       at okio.GzipSource.read(GzipSource.java:62)
       at okio.internal.BufferKt.commonWriteAll(BufferKt.java:1061)
       at okio.Buffer.writeAll(Buffer.java:1655)
       at okio.internal.RealBufferedSourceKt.commonReadUtf8(RealBufferedSourceKt.java:171)
       at okio.RealBufferedSource.readUtf8(RealBufferedSource.java:309)
       ...
       at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:423)
       at java.util.concurrent.FutureTask.run(FutureTask.java:237)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
       at java.lang.Thread.run(Thread.java:818)

[swankjesse]

What version of Okio is this? I don't think we've ever had a okio.InflaterSource.readOrInflate() function. Is Samsung being naughty and shipping broken Okio?

[ppamorim]

@swankjesse I am not sure, I can see that this function has been added to Okio in the version 2.6.0:

https://square.github.io/okio/changelog/#version-260

I can see that OkHttp has it (version 2.7.0) in the dependencies:

https://github.com/square/okhttp/blob/master/build.gradle#L20

I can find the very same function in the version 2.7.0 here:

https://github.com/square/okio/blob/349809cd53db10fdec4cbd1194f1c3e7657f8e5a/okio/src/jvmMain/kotlin/okio/InflaterSource.kt#L65

Now I am confused.

[swankjesse]

I think it's me who is confused. The stacktrace says .java but corresponds to .kt files?

[yschimke]

https://stackoverflow.com/questions/57518909/why-do-kotlin-files-appear-as-java-is-fabric-crashlytics-with-proguard-enabled

[swankjesse]

Is the example above sufficient to reproduce this? I'm surprised google.com is returning 200 from that request.

[swankjesse]

A web search for the exception suggests the server is not returning well-formed gzip data. You should request the server's administrators fix the problem.

In the interim you can disable compression with this request header:

Accept-Encoding: identity