René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Docker 18.06: copyArchiveFromContainerCmd fails due to presence of gzip encoding","articleBody":"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).\r\n\r\nWe believe that we've traced it back to the following causes:\r\n\r\n1. 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\r\n1. Content negotiation to produce compressed responses were added to Docker in moby/moby#36164, meaning that TAR archives will now come back with gzip/deflate compression according to the request header\r\n1. AFAICT, despite the `Accept-Encoding` request header, there is no code in docker-java to actually decompress responses\r\n\r\nIt 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.","author":{"url":"https://github.com/rnorth","@type":"Person","name":"rnorth"},"datePublished":"2018-08-04T15:23:30.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1},"url":"https://github.com/1079/docker-java/issues/1079"}