
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote type="cite" class=""><span class="">On Wednesday, March 25, 2015 12:04:03 PM Jason Woods wrote:</span><br class=""><blockquote type="cite" class=""><span class="">Hi,</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">I have a (probably dodgy) application that is sending out uncompressed XML</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">with the following header. That is, an empty Content-Encoding header.</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Content-Encoding:</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">This works fine, until I enable gzip on Nginx 1.6.2 latest (which is a proxy</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">to the application.) Nginx compresses the XML, and adds ANOTHER</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Content-Encoding header, containing "gzip". I end up with this response:</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Content-Encoding:</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Content-Encoding: gzip</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">This seems to break on Safari and Google Chrome (not tested other browsers.)</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">They seem to ignore the latter header, and assume that content is not</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">compressed, and try to render the binary compressed output. Is this an</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">issue in the client implementations, an issue in the Nginx GZIP</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">implementation, an issue in the upstream application, or a mixture of all</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">3?</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Looking at Nginx 1.6.2's ngx_http_gzip_filter_module.c lines 246 to 255</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">(which I believe is the correct place) it checks for existence of a</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Content-Encoding header with a positive length (non-zero) - so it looks</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">like if any other Content-Encoding was already specified, Nginx GZIP does</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">not do anything and does not duplicate header. So it seems the case of an</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">empty Content-Encoding slips through. Should this be the case? Should it</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">remove the existing blank header first, or just not GZIP if it exists and</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">is empty?</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Thanks in advance,</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Jason</span></blockquote></blockquote><div class=""><font color="#000000" class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">On 25 Mar 2015, at 19:08, Styopa Semenukha <<a href="mailto:semenukha@gmail.com" class="">semenukha@gmail.com</a>> wrote:<br class=""></span></font></div><blockquote type="cite" class=""><font color="#000000" class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class="">Probably discarding the Content-Encoding directive from the upstream will <br class="">resolve this:<br class=""><a href="http://nginx.org/r/proxy_hide_header" class="">http://nginx.org/r/proxy_hide_header</a></span></font></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><br class=""></blockquote><span class="">-- </span><br class=""><span class="">Best regards,</span><br class=""><span class="">Styopa Semenukha.</span><br class=""></blockquote><div class="">(Apologies - resending on-list.)</div><br class=""><div class="">Thanks I'll give that a go!</div><div class=""><br class=""></div><div class="">Though I do think this might be incorrect Nginx behaviour as the header should be modified not duplicated.</div><div class=""><br class=""></div><div class="">I'd like to find out if that is the case. Hopefully an easy fix that will save others time down the line!</div><div class=""><br class=""></div><div class="">Jason</div></body></html>