On 01/08/2016 08:49 AM, Jan Kaluža wrote:
Hi,
it seems Docker client has a problem handling httpd responses [1] when
you run Docker server behind httpd working as a reverse proxy. It is
caused by "mod_mime_magic" adding following Content-Type and
Content-Encoding to gzipped tarballs sent as a response by Docker server:
Just to correct myself a bit. I have found out it's not a reverse-proxy
case - in that case, mod_mime_magic would not be in the loop. They are
just serving Docker data using following config:
https://github.com/rbarlow/pulp_docker/blob/master/plugins/etc/httpd/conf.d/pulp_docker.conf
Content-Type: application/x-tar
Content-Encoding: x-gzip
Docker client expects gzipped tarballs to be received, but because it
receives Content-Encoding: x-gzip, it decompresses the response and
receives just plain tar (at least that's how I understand it).
Strictly speaking, httpd is probably right here according to RFC:
"""
The Content-Encoding entity-header field is used as a modifier to the
media-type. When present, its value indicates what additional content
codings have been applied to the entity-body, and thus what decoding
mechanisms must be applied in order to obtain the media-type referenced
by the Content-Type header field.
"""
So, the mod_mime_magic is saying here that the body is tarball encoded
by gzip.
But I think even we are right here, the Content-Encoding should be used
only when httpd itself encodes the original content, otherwise it
confuses clients (I've asked few people and it confuses some web
browsers too - I can get more info if needed.).
Maybe we could stop setting Content-Encoding in mod_mime_magic and just
use Content-Type?
[1] https://github.com/docker/docker/issues/17595
Regards,
Jan Kaluza
Regards,
Jan Kaluza
