[BUG] Gunzip module may cause requests to fail

Aviram Cohen aviram at adallom.com
Mon Nov 30 16:29:09 UTC 2015


You are right, response bodies that are empty but still "encoded as gzip" are a bit malformed.
Unfortunately, sometimes we don't control the behavior of the server. And still, I think Nginx should be able to handle such responses and not disconnect the client.


-----Original Message-----
From: nginx-devel [mailto:nginx-devel-bounces at nginx.org] On Behalf Of Valentin V. Bartenev
Sent: יום ב 30 נובמבר 2015 17:16
To: nginx-devel at nginx.org
Subject: Re: [BUG] Gunzip module may cause requests to fail

On Monday 30 November 2015 13:20:02 Aviram Cohen wrote:
> Hello!
> A couple of years ago, I've reported the following bug:
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmailma
> n.nginx.org%2fpipermail%2fnginx-devel%2f2013-October%2f004442.html&dat
> a=01%7c01%7cavcohe%40064d.mgd.microsoft.com%7cc38e39e22c5742dc11e908d2
> f999378d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=58REjgVeya98VvYp
> wf6WE3veHmoaixSkNS8neZWFgi0%3d
> Responses with empty bodies with the header "Content-Encoding: gzip" used to cause requests to hang.
> There has been a fix, but now it seems that the requests simply fails.
> Reviewing the code, it appears that the following happens:
> - An empty last buffer arrives into the gunzip module's body filter.
> - The gunzip module's ngx_http_gunzip_filter_add_data() calculates and 
> input buffer size (it is 0), and it is later in fed to zlib's 
> inflate(), along with the paramter Z_FINISH
> - inflate() is later called, and returned Z_BUF_ERROR. This causes error handling to shut down the request and the connection. The client gets an empty response.
> I'm not sure what a proper fix would be, but I can suggest the following:
> 1. In ngx_http_gunzip_header_filter() check the content length, and don't create a gunzip ctx if it is 0.
> 2. In ngx_http_gunzip_body_filter(), check if gunzip has started ("!ctx->started"). If it hasn't and the input buffer is the last one, simply jump to the next filter. This handles the case that the response with is chunked encoding.
> Would be great to hear the development team's opinion.

Why do you think that it's a bug in nginx?

For me "Content-Encoding gzip" without gzip wrapper doesn't look like a valid gzip encoded response.

  wbr, Valentin V. Bartenev

nginx-devel mailing list
nginx-devel at nginx.org

More information about the nginx-devel mailing list