feature: allow use of ngx.exit() in the context of body_filter_by_lua_*

[rainingmaster]

Ported from header_filter_by_lua, I have try to add a new feature that add ngx.exit() in the context of body_filter_by_lua. But like in the context of balance_by_lua_*, we can not set return code. Run ngx.exit() in body_filter_by_lua_* will stop immediately, but return a code before.

I hereby granted the copyright of the changes in this pull request to the authors of this lua-nginx-module project.

[agentzh]

@rainingmaster Always returning NGX_OK in our body filter handler on the C land is wrong. We should return NGX_ERROR to signal the content handler to stop continuing immediately when the user calls ngx.exit(ngx.ERROR) or the argument is a code no smaller than 300.

[rainingmaster]

@agentzh run ngx.exit() first time in body_filter will return NGX_OK because I think we should use follow body_filter to filter the output buffer， and NGX_ERROR will be return while ctx.body_exited sign to stop continuing immediately. Do you mean we should judge the rc is ngx.ERROR or the argument is a code no smaller than 300 when ngx.exit() is executed in the bodyfilter phase?

[agentzh]

@rainingmaster Yes, otherwise the content handler will simply generate more data and continue calling the body filter chain.

[rainingmaster]

@agentzh Should we judge the rc is ngx.ERROR or the argument is a code no smaller than 400 here? However, this status code cannot be response to the client, so I don't think it's necessary to limit the status code

[agentzh]

@rainingmaster I think we should just throw out a Lua exception when a meaningless status code is provided as the argument. We should limit automatic nginx error logging in our Lua API. Catch the error on the low level, and let the upper levels handle the error. This ngx.exit() is a low level API, so it should not handle the error by make the decision by itself to log the error.

[rainingmaster]

@agentzh Well, I've tried to change the nginx error logging to a Lua exception. Is that right like this?

[rainingmaster]

@agentzh Can you help me see if there are any more questions? We plan to use massively online. Thanks：)

[hongliang5316]

@agentzh Our customers have such a distorted demand scenario: They require real-time control of an asynchronous request, when the request comes in, we need to request the third party asynchronous interface, third party interface will tell us whether the request should be terminated immediately, but the length of time requested by the third party interface does not affect the flow of this request,If this request has not yet ended, the third party interface is required to terminate, then we must terminate this request, in order to achieve this effect, we consider the implementation of the body_filter phase.Do you have another idea about this?Thanks for your help very much.

[luksbelt]

Question: this feature will be included in some future release? thanks

[agentzh]

@luksbelt Well, @thibaultcha might help take care of this.

[rainingmaster]

@thibaultcha could you help me check these code, I have rebase the newest code now, thank you

[rainingmaster]

@doujiang24 Finish, could you help me check again?

[rainingmaster]

@thibaultcha Hello, could you help me review this pr? So thanks

[mergify[bot]]

This pull request is now in conflict :(