[BUG] Gunzip module may cause requests to fail

Aviram Cohen aviram at adallom.com
Tue Dec 1 07:55:22 UTC 2015


Maxim, great hearing from you.
I have said that the response is a bit malformed, which means for me that even though it looks weird, it can be handled.
You are right that when Nginx gets unpredicted behaviors from the server/client, it should close the connection so that there won't be any damage.
However, this is an error that Nginx could have easily avoided.

Besides, this is not an explicit Nginx behavior, as Nginx is not aware that it got an empty response with the gzip header.
It happens implicitly due to a calculation of data size, which happens to be zero. The error log doesn't show a backend server error, but a zlib error.
This all suggests an obvious Nginx bug, and doesn't sound to me like the desired Nginx behavior.

Best regards,

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


On Mon, Nov 30, 2015 at 04:29:09PM +0000, Aviram Cohen wrote:

> 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.

As you said, such responses are "a bit malformed".  And nginx does its best at handling such malformed responses: it logs an error and closes the connection to prevent further damage.

The only potentially better option I can think of would be to don't touch such responses at all.  Unfortunately, this isn't really possible as response headers are already modified and sent to the client at the point when we know the response body is malformed.

Another obvious solution would be to instruct nginx to don't try to gunzip responses if you don't control responses of your backend and there are malformed ones.  Actually, this is the default.

Maxim Dounin

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

More information about the nginx-devel mailing list