Hello!
On Thu, Nov 28, 2013 at 07:39:32PM +1030, SplitIce wrote:
> I am aware atleast 2 others are considering developing patches with one the
> module maintainer.
>
> I wanted to improve so have attempted this upgrade myself. Its only a small
> patch, from my understanding its the upstream length field that has changed
> between 1.4.x and 1.5.x.
>
> I would like to know if I have done something I shoudnt etc so as to
> improve my nginx knowledge.
>
> The commits -
> https://github.com/splitice/ngx_http_redis/commit/88d423c17a8614b29635994839649c3e0d576641
> https://github.com/splitice/ngx_http_redis/commit/c7dbe9fa75001787bd6602c4029e0e314798a37d
>
> I always find myself worried that I will do something that will have
> strange flow on effects e.g at a certain length in a buffer etc.
You mean adoption for the API change in nginx 1.5.3:
*) Change in internal API: now u->length defaults to -1 if working with
backends in unbuffered mode.
(quote from http://nginx.org/en/CHANGES)?
You patches look wrong for me, correct one should be like the
change to memcached module in this commit:
http://hg.nginx.org/nginx/rev/f538a67c9f77
That is, in u->length should be explicitly set in filter init
callback, not just incremented from a default value (which was
changed).
Something like this should work (not tested):
--- ngx_http_redis_module.c.orig 2013-11-28 13:35:28.000000000 +0400
+++ ngx_http_redis_module.c 2013-11-28 13:37:19.000000000 +0400
@@ -578,7 +578,7 @@ ngx_http_redis_filter_init(void *data)
u = ctx->request->upstream;
- u->length += NGX_HTTP_REDIS_END;
+ u->headers_in.content_length_n + NGX_HTTP_REDIS_END;
return NGX_OK;
}
Author CC'd.
--
Maxim Dounin
http://nginx.org/en/donation.html
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
