-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Docker 18.06: copyArchiveFromContainerCmd fails due to presence of gzip encoding #1079
Comments
This was referenced Aug 4, 2018
This was referenced Aug 6, 2018
rnorth
added a commit
to rnorth/docker-java
that referenced
this issue
Aug 14, 2018
This was referenced Sep 14, 2018
This was referenced Oct 5, 2018
This was referenced Oct 14, 2018
ivankelly
added a commit
to ivankelly/pulsar
that referenced
this issue
Jan 9, 2019
The previous version was using a version of docker-java which didn't handle gzip compression well. So if the docker api returned an response that was gzip compressed, it wouldn't be decompressed and then log dumping would gzip it again, and then tar zxvf wouldn't handle it. See docker-java/docker-java#1079.
merlimat
pushed a commit
to apache/pulsar
that referenced
this issue
Jan 9, 2019
The previous version was using a version of docker-java which didn't handle gzip compression well. So if the docker api returned an response that was gzip compressed, it wouldn't be decompressed and then log dumping would gzip it again, and then tar zxvf wouldn't handle it. See docker-java/docker-java#1079.
This was referenced Apr 15, 2019
Great investigation by @rnorth ! I also started hitting this when I switched to NettyDockerCmdExecFactory. Then I realized it is time to update docker-java :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
NettyInvocationBuilder
sets an outgoingAccept-Encoding: gzip
header. Until very recently docker was not actually doing anything with this header - i.e. not producing a compressed responseAccept-Encoding
request header, there is no code in docker-java to actually decompress responsesIt seems to me that a simple fix is to add
channel.pipeline().addLast(new HttpContentDecompressor())
in the right places inNettyInvocationBuilder
. If this works for us (and our forked version of this class), I'll contribute a PR back to docker-java.The text was updated successfully, but these errors were encountered: