Docker 18.06: copyArchiveFromContainerCmd fails due to presence of gzip encoding

[rnorth]

We've observed an issue affecting users of Testcontainers and Docker 18.06 on Mac, whereby our attempts to copy a file from a container would fail (producing zero-length or corrupt data).

We believe that we've traced it back to the following causes:

1. docker-java’s NettyInvocationBuilder sets an outgoing Accept-Encoding: gzip header. Until very recently docker was not actually doing anything with this header - i.e. not producing a compressed response
2. Content negotiation to produce compressed responses were added to Docker in Content encoding negotiation added to archive request. moby/moby#36164, meaning that TAR archives will now come back with gzip/deflate compression according to the request header
3. AFAICT, despite the Accept-Encoding request header, there is no code in docker-java to actually decompress responses

It seems to me that a simple fix is to add channel.pipeline().addLast(new HttpContentDecompressor()) in the right places in NettyInvocationBuilder. If this works for us (and our forked version of this class), I'll contribute a PR back to docker-java.

[tgeorgiev]

Great investigation by @rnorth ! I also started hitting this when I switched to NettyDockerCmdExecFactory. Then I realized it is time to update docker-java :)