Hi Jason, Probably discarding the Content-Encoding directive from the upstream will resolve this: http://nginx.org/r/proxy_hide_header
On Wednesday, March 25, 2015 12:04:03 PM Jason Woods wrote: > 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 -- Best regards, Styopa Semenukha. _______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
