"gzip on" duplicates Content-Encoding header if an empty one already exists

[Styopa Semenukha]

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
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
-- 
Best regards,
Styopa Semenukha.