Hi, I have a (probably dodgy) application that is sending out uncompressed XML with the following header. That is, an empty Content-Encoding header.
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: Content-Encoding: Content-Encoding: gzip 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 output. 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, Jason _______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
