I have a (probably dodgy) application that is sending out uncompressed
XML with the following header. That is, an empty Content-Encoding
This works fine, until I enable gzip on Nginx 1.6.2 latest (which is a
proxy to the application.) Nginx compresses the XML, and adds ANOTHER
Content-Encoding header, containing “gzip”.
I end up with this response:
This seems to break on Safari and Google Chrome (not tested other
browsers.) They seem to ignore the latter header, and assume that
content is not compressed, and try to render the binary compressed
Is this an issue in the client implementations, an issue in the Nginx
GZIP implementation, an issue in the upstream application, or a mixture
of all 3?
Looking at Nginx 1.6.2’s ngx_http_gzip_filter_module.c lines 246 to 255
(which I believe is the correct place) it checks for existence of a
Content-Encoding header with a positive length (non-zero) - so it looks
like if any other Content-Encoding was already specified, Nginx GZIP
does not do anything and does not duplicate header. So it seems the case
of an empty Content-Encoding slips through. Should this be the case?
Should it remove the existing blank header first, or just not GZIP if it
exists and is empty?
Thanks in advance,