[BUG] Gunzip module may cause requests to fail

Aviram Cohen aviram at adallom.com
Wed Dec 2 07:39:25 UTC 2015


Hello!

Maxim, I want to set up a reverse proxy the gunzips responses of a backend server I cannot control (for example, a cache server for a development infrastructure).
The response is marked with Content-Length set to zero, so Valentin's comment regarding why the response is empty is irrelevant. It is also irrelevant when the server sends a chunked response with an initial 0 sized chunk. I've seen servers that do both.
The HTTP level is okay besides the extra gzip header, and so this is a "little bit pregnant" response ;)
HTTP clients such as web browsers, wget and curl do handle this response, but my reverse proxy doesn't.
What do you suggest that I'd do?

Regarding the error description itself, a patch that can applied to better describe the error seems as easy for me as a fix, so to me it seems irrelevant as long as you refuse to fix the issue.
Obviously I can provide a patch for the issue itself, which I still consider as an Nginx bug :)

Regards
Aviram

-----Original Message-----
From: nginx-devel [mailto:nginx-devel-bounces at nginx.org] On Behalf Of Maxim Dounin
Sent: יום ג 01 דצמבר 2015 15:29
To: nginx-devel at nginx.org
Subject: Re: [BUG] Gunzip module may cause requests to fail

Hello!

On Tue, Dec 01, 2015 at 07:55:22AM +0000, Aviram Cohen wrote:

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

"Just a little bit pregnant" (c)

The response is malformed, and nobody knows how it is expected to 
look like if it wasn't malformed.

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

The error happens when gunzipping the response, and it's 
irrelevant if it was obtained from a backend or from disk.

The error says "inflate() returned ... on response end", and it is 
belived to be clear enough and in line with other errors reported 
by gunzip filter.  If you think the error message can be improved - 
feel free to suggest patches.

-- 
Maxim Dounin
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fnginx.org%2f&data=01%7c01%7cavcohe%40064d.mgd.microsoft.com%7c0717e54f7a5341e676bc08d2fa535a2e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=iY0M%2f3q3EydPoDgArT%2f7haglLl1PDvWF5ctvuIFcBOg%3d

_______________________________________________
nginx-devel mailing list
nginx-devel at nginx.org
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmailman.nginx.org%2fmailman%2flistinfo%2fnginx-devel&data=01%7c01%7cavcohe%40064d.mgd.microsoft.com%7c0717e54f7a5341e676bc08d2fa535a2e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=zkaAsixoTcePtFD8bAvpiK9XO%2f7pPENlIrXmDvEItrk%3d



More information about the nginx-devel mailing list