feature: add precontent_by_lua directives #2472
Open
+1,100
−4
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I hereby granted the copyright of the changes in this pull request
to the authors of this lua-nginx-module project.
Since balancer_by_lua_block does not support consocket, getting upstream peers from the outside is usually performed in the access_by_lua_*. (refer to https://github.com/openresty/lua-nginx-module?tab=readme-ov-file#balancer_by_lua_block)
However, since the access phase is mainly responsible for access control, many subrequests usually skip the access phase, resulting in subrequests being unable to get upstream peers in the access phase. The current solution is to identify sub-requests and then move the relevant processing logic forward to rewrite_by_lua_*. But it is ultimately an unreasonable solution, as it inappropriately utilizes the rewrite or access phase to provide functionality that does not belong to them.
In nginx, there is actually a precontent phase after the post_access phase. Initially, nginx named this phase
NGX_HTTP_TRY_FILES_PHASE, and it was a dedicated phase for the try_files module (other module handlers could not be registered). As nginx's functionality expanded, it was renamedNGX_HTTP_PRECONTENT_PHASE, which also allowed the registration of new module handlers.By injecting Lua code into the precontent phase, we can implement proxy/upstream-related preparation functions, including upstream header rewriting, proxy authentication, proxy URI rewriting, and upstream information retrieval (such as obtaining the upstream peer list via DNS). Furthermore, the precontent phase will not be bypassed in sub-requests (one of the biggest problems with registering non-access control related functions in the access phase).
This PR added 3 directives:
The PR for lua-resty-core: openresty/lua-resty-core#519
close #2253