Issue in Lua-nginx-module when use both ngx.location.capture and ngx.exec

[Wendal Chen]

My Pleasure, ^_^

Wating for your fixed version [?]

在 2011年3月17日 下午2:44，agentzh <agentzh at gmail.com>写道：

> On Tue, Mar 15, 2011 at 7:45 PM, Wendal Chen <wendal1985 at gmail.com> wrote:
> >
> > #用中文再说一遍,英语水平有限:
> > 我得到的最小集合就是:
> > 1. nginx.conf
> > location /test {
> >     root html;
> >     content_by_lua_file "conf/test.lua";
> > }
> > server/http等配置按默认的, event module用的是 epoll
> >
> > 2. test.lua文件仅2行:
> > ngx.location.capture('/1.html')
> > ngx.exec("/1.html")
> >
> > 我尝试过,无论这两句话是否请求同一个文件,结果都一样.
> >
> > 3. 1.html文件里面仅有几个字母,我已经试过不同的文件大小,结果一样
> >
> >
> > 我遇到的情况是这样的:
> > 1. 通过wget/curl/Firefox来访问 localhost/test 都能正常显示1.html中的内容
> > 2. 使用ab访问 localhost/1.html是正常的,能够pass
> > 3. 使用ab进行测试,总是timeout ,
>
> I've reproduced it on my side. This is indeed a bug. When ngx.exec()
> is used after ngx.location.capture() or ngx.location.capture_multi(),
> nginx 0.8.11+ will not close the client connection due to leaked
> request reference counter (r->main->count). A hacky work-around is to
> disable nginx http keepalive and rely on the browser (and other http
> clients) to actively close the connection. And that's why wget, curl,
> firefox, and other well-written http clients worked for you.
>
> Nginx 0.7.68 (and older) is confirmed to work in this context just
> because older nginx does not use reference counting.
>
> I'll attempt fix in the next few days. Thank you for reporting this
> and sorry about this issue :)
>
> Cheers,
> -agentzh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20110317/90115de3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 96 bytes
Desc: not available
URL: <http://nginx.org/pipermail/nginx/attachments/20110317/90115de3/attachment.gif>