Yes that seems much better than taking over the u->headers_in.content_length_n field.
Didn't realize just how similar memcache was :) Thanks. On Thu, Nov 28, 2013 at 8:10 PM, Maxim Dounin <mdou...@mdounin.ru> wrote: > 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 >
_______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
