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:[email protected]] On Behalf Of Maxim Dounin Sent: יום ג 01 דצמבר 2015 15:29 To: [email protected] 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 [email protected] 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 _______________________________________________ nginx-devel mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-devel
