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

[Jason Woods]

> 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
On 25 Mar 2015, at 19:08, Styopa Semenukha <semenukha at gmail.com <mailto:semenukha at gmail.com>> wrote:
> 
> Probably discarding the Content-Encoding directive from the upstream will 
> resolve this:
> http://nginx.org/r/proxy_hide_header <http://nginx.org/r/proxy_hide_header>
> -- 
> Best regards,
> Styopa Semenukha.
(Apologies - resending on-list.)

Thanks I'll give that a go!

Though I do think this might be incorrect Nginx behaviour as the header should be modified not duplicated.

I'd like to find out if that is the case. Hopefully an easy fix that will save others time down the line!

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20150331/664c5054/attachment-0001.html>