Document/disable OkHttp's automatic response decompression

[ianbotsf]

Describe the bug

Getting a compressed object from S3 with S3Client.getObject when using the default OkHttp engine returns the body uncompressed instead of in its original, persisted form. This is because OkHttp automatically accepts and decompresses GZipped responses. This behavior is surprising and differs from CRT engine and the Java v2 SDK, both of which return the compressed object body.

Expected Behavior

Users are not surprised by unexpectedly decompressed objects.

Steps to Reproduce

This code shows the issue:

val uncompressed = ByteArray(1024) { it.mod(Byte.MAX_VALUE) }
val compressed = ByteArrayOutputStream()
    .also { GZIPOutputStream(it, true).apply {
        write(uncompressed)
        flush()
        close()
    } }
    .toByteArray()
println("Uncompressed length: ${uncompressed.size}") // Uncompressed length: 1024
println("Compressed length: ${compressed.size}") // Compressed length: 164

runBlocking {
    S3Client.fromEnvironment().use { s3 ->
        s3.putObject {
            bucket = "<some-bucket>"
            key = "compression-test"
            contentEncoding = "gzip"
            body = ByteStream.fromBytes(compressed)
        }

        s3.getObject(GetObjectRequest {
            bucket = "<some-bucket>"
            key = "compression-test"
        }) {
            println("Response length: ${it.body?.toByteArray()?.size}") // Response length: 1024
        }
    }
}

Possible Solution

We should either:

• document this behavior more clearly
• offer HTTP engine settings to change it
• disable the OkHttp transparent decompression altogether

Context

Currently available workarounds include setting responseContentEncoding = "identity" in the GetObjectRequest, adding an interceptor to accomplish the same thing, or using the CRT engine.

Your Environment

• Smithy Kotlin version used: 1.0.15
• Platform (JVM/JS/Native): OpenJDK 8
• Operating System and version: Amazon Linux 2

[aajtodd]

https://github.com/square/okhttp/blob/master/okhttp/src/main/kotlin/okhttp3/internal/http/BridgeInterceptor.kt#L65-L107

[ianbotsf]

After discussing this we consider this behavior incongruent with other HTTP engines and other AWS SDKs. Our best fix will be to disable transparent decompression altogether, likely by manually setting Accept-Encoding: identity when we construct the OkHttp request object.