Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

rainingmaster
Copy link
Member

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
Copy link
Member

agentzh commented Mar 10, 2017

@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
Copy link
Member Author

@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
Copy link
Member

agentzh commented Mar 10, 2017

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

@rainingmaster
Copy link
Member Author

rainingmaster commented Mar 10, 2017

@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
Copy link
Member

agentzh commented Mar 13, 2017

@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
Copy link
Member Author

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

@rainingmaster rainingmaster force-pushed the bodyfilter_exit branch 2 times, most recently from 1c73e76 to aefc821 Compare March 20, 2017 13:45
@rainingmaster
Copy link
Member Author

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

@rainingmaster rainingmaster force-pushed the bodyfilter_exit branch 6 times, most recently from 0496697 to 6802279 Compare April 6, 2017 12:25
@hongliang5316
Copy link
Contributor

hongliang5316 commented Apr 7, 2017

@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
Copy link

luksbelt commented Dec 4, 2018

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

@agentzh
Copy link
Member

agentzh commented Feb 4, 2019

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

@rainingmaster rainingmaster force-pushed the bodyfilter_exit branch 3 times, most recently from 461f1cf to df726d0 Compare March 28, 2020 03:16
@rainingmaster
Copy link
Member Author

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

@rainingmaster rainingmaster requested a review from agentzh March 28, 2020 03:50
@rainingmaster
Copy link
Member Author

@doujiang24 Finish, could you help me check again?

@rainingmaster
Copy link
Member Author

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

@mergify
Copy link

mergify bot commented Sep 20, 2021

This pull request is now in conflict :(

@mergify
Copy link

mergify bot commented Mar 20, 2023

This pull request is now in conflict :(

@mergify mergify bot added the conflict label Mar 20, 2023
@mergify mergify bot removed the conflict label May 10, 2023
@mergify
Copy link

mergify bot commented May 10, 2023

This pull request is now in conflict :(

@mergify mergify bot added the conflict label May 10, 2023
@mergify mergify bot removed the conflict label Sep 23, 2023
@mergify
Copy link

mergify bot commented Sep 23, 2023

This pull request is now in conflict :(

@mergify mergify bot added the conflict label Sep 23, 2023
Copy link

mergify bot commented Mar 6, 2024

This pull request is now in conflict :(

@mergify mergify bot removed the conflict label Feb 13, 2025
Copy link

mergify bot commented Feb 13, 2025

This pull request is now in conflict :(

@mergify mergify bot added the conflict label Feb 13, 2025
@mergify mergify bot removed the conflict label May 7, 2025
Copy link

mergify bot commented May 7, 2025

This pull request is now in conflict :(

@mergify mergify bot added the conflict label May 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants