Client disconnect in ngx_http_image_filter_module

Dan Podeanu pdan at
Tue Apr 28 09:56:54 UTC 2015

I have encountered a bug in ngx_http_image_filter_module when used in conjunction with ngx_http_proxy_module ; the configuration is as following:

location /img/ {
	proxy_pass <>;
	image_filter resize 150 100;

The steps to reproduce are rather complicated as they depend on how TCP fragments the response coming from the proxy:

- If <> returns, in the first TCP packet, a sizable amount of data (1-2k), the image is resized correctly.

- If <> returns, in the first TCP packet, a small amount of data (HTTP header, or HTTP header + a few bytes), the content is marked as not an image and NGX_HTTP_UNSUPPORTED_MEDIA_TYPE is returned (disconnecting the client), irrespective on whether or not subsequent data would complete the response to a valid image.

Nginx appears to give up right away on waiting for data if the contents of the first TCP packet received from the proxy does not contain a valid image header- i.e. ngx_http_image_test() will return NGX_HTTP_IMAGE_SIZE, etc.

In my experience this was triggered by a subtle change in AWS S3 that fragments the TCP header more.

Versions affected: 1.6.2, 1.6.3, 1.7.2, 1.8.0, etc.

Attaching a patch which fixes it for my use case (1.6.2) below; the other versions can be fixed similarly:

diff -ruN nginx-1.6.2.orig/src/http/modules/ngx_http_image_filter_module.c nginx-1.6.2/src/http/modules/ngx_http_image_filter_module.c
--- nginx-1.6.2.orig/src/http/modules/ngx_http_image_filter_module.c	2014-09-16 19:23:19.000000000 +0700
+++ nginx-1.6.2/src/http/modules/ngx_http_image_filter_module.c	2015-04-28 16:25:47.000000000 +0700
@@ -317,9 +317,8 @@
-            return ngx_http_filter_finalize_request(r,
-                                              &ngx_http_image_filter_module,
-                                              NGX_HTTP_UNSUPPORTED_MEDIA_TYPE);
+            /* wait to consume more data, do not give up on the request right away */
+            return NGX_OK;
         /* override content type */

Thoughts ? Is this the right fix ? Should I also post on the nginx Trac ?

Thank you,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the nginx-devel mailing list