extra handler to process for all the other requests.
I do not fully grok your approach but I’d ask first: will this
approach allow subrequests, internal redirection, non-blocking sleep,
and all the other fancy stuffs?
If you were just wrapping around set_var, then no. It would only be
able to handle non-reentrant code, just like setby.
In order to have reentrant code, it would need to have a generic layer
that would be able to jump in/out of the script engine (and handle
re-calling the script engine post subrequest etc). The rewrite handler
would also need to be re-written to handle re-entering the script
engine.
The advantage of having a generic rewrite re-entrant layer, though,
would be that set_var would also be able to accept subrequests etc
(assuming you used that to base setby on).
Would it mean “if” blocks? The last, redirect, permanent etc flags
available to rewrite are very convenient.
myself.
changing it now would break other stuff.
I doubt it Unless one only jump to named locations and never to
normal locations. The behaviors here are already inconsistent and very
hard to work around.
Pardon my ignorance. I thought it was the same thing.
Anyway, Marcus has lent his weight to your call so hopefully it will
get picked up and implemeted.
Would it mean “if” blocks? The last, redirect, permanent etc flags
available to rewrite are very convenient.
Making different Nginx modules work together requires a bit more
understanding of how things work behind the scene, like phase handler
running order and etc.
Nginx is full of dark magic already. That’s the Nginx way of doing
things (at least for now) and let’s face it.
Do not expect everything to work intuitively for multi-module
scripting especially when interacting with ngx_rewrite. And that’s why
I suggest staying in pure Lua as much as possible.
If you were just wrapping around set_var, then no. It would only be able to
handle non-reentrant code, just like setby.
Gathered so I asked because I didn’t want to miss any quick magic
Nope. WYSIWYG.
In order to have reentrant code, it would need to have a generic layer that
would be able to jump in/out of the script engine (and handle re-calling the
script engine post subrequest etc). The rewrite handler would also need to
be re-written to handle re-entering the script engine.
The advantage of having a generic rewrite re-entrant layer, though, would be
that set_var would also be able to accept subrequests etc (assuming you used
that to base setby on).
I’ve been waiting for this feature for more than a year now
Well, I’ve built a more generic scripting framework that implements
ngx_http_script_xxx - type stuff at any phase for which you can define
handlers, not just the rewrite phase, and have build a large number of
functions that work of this framework (echo, memcache, json parsing,
arrays, math functions, shell_exec and a bunch of other things). It is
almost able to do everything that you can do in ngx_lua (not quite, but
I’m getting there), as well as a few things I’ve not seen in Lua, and it
also works with the ngx_tcp_module (so you can do scripting on arbitrary
TCP traffic as well as at the various phases of HTTP requests). I’ve
had it running in production for a while, and am actively developing it,
I just haven’t open-sourced it yet (I’m not sure yet whether I will or
not, so I’m holding off on doing so for the time being).
I could probably make what I’ve done work with the current Nginx and NDK
code, but since I’m not using the NDK set_var stuff for this scripting
stuff, I don’t intend on spending quite a bit of time developing
something for the NDK that I’m never going to use.
Do not expect everything to work intuitively for multi-module
scripting especially when interacting with ngx_rewrite. And that’s why
I suggest staying in pure Lua as much as possible.
Makes sense to stick to one given that each is independent of the other.
Just so tempting/logical on the surface, when they all go into the
same location block for instance, to try to pick and choose elements
from each.
In my example, the flags from rewrite with the single line syntax is
nice, clear and familiar but it does not provide a native mechanism to
jump to another specific location (perhaps Igor would consider
allowing try_files to accept a single argument).
Anyway, learnt a bit more and I will like to say thank you very much
for the work put in to the various weird and wonderful modules you
have pushed out.
The modules open up a huge amount of options and really take Nginx to
another level.
Everything seems to be working fine. However, a small configuration
error showed a potential problem in that the rewrite_by_lua directive
does not seem to take account of the rewrite module’s “last” flag.
I’ve just fixed this issue in ngx_lua v0.3.1rc13.
Now running “rewrite a b;” and “rewrite a b last;” will cause
rewrite_by_lua and rewrite_by_lua_file (as well as others) to skip
completely.
But please note that, only location rematch (or location re-lookup)
triggered by ngx_rewrite’s “rewrite” directive (or anything else) will
skip rewrite phase Lua code. It has nothing to do with rewrite
directive’s “last” modifier. So “rewrite a b break” will not skip
rewrite-phase Lua handlers just because no location re-lookup will
follow it.
The location rematch (or re-lookup) behavior of the “rewrite”
directive is kinda like internal redirection, but not the same.
BTW, ngx_openresty 1.0.8.9 devel release already includes this version
of ngx_lua
Makes sense to stick to one given that each is independent of the other.
Just so tempting/logical on the surface, when they all go into the
same location block for instance, to try to pick and choose elements
from each.
That’s all what we dream about, but the reality of the nginx internals
are sad in various ways and have been preventing us from doing a lot
of fancy things without hacking or even patching
In my example, the flags from rewrite with the single line syntax is
nice, clear and familiar but it does not provide a native mechanism to
jump to another specific location (perhaps Igor would consider
allowing try_files to accept a single argument).
You can now do what the “rewrite” directive does in pure Lua since the
latest ngx_lua v0.3.1rc13 release.
location @pretty_urls {
rewrite_by_lua '
if ngx.var.uri == "/sometext/xyz.html" then
return ngx.req.set_uri("/abc.html")
end
ngx.exec("@proxy");
';
}
I think it’s also clean and readable as compared to the “rewrite”
directive, but much more flexible.
See the documentation here for details:
Anyway, learnt a bit more and I will like to say thank you very much
for the work put in to the various weird and wonderful modules you
have pushed out.
The modules open up a huge amount of options and really take Nginx to
another level.
Glad you like it! And thank YOU for reporting all these issues during
your adventure
been in any formal releases of my modules
No problem and to be expected … which is why I normally don’t
install the rc versions and why I am still at 0.3.1rc11 which works
just fine for me.
I’ll stay with 0.3.1rc11 and swing back to the formal release cycle
down the line.
I’ll also keep the rewrite module as my default tool (A series of one
line “rewrite a b last” calls is easier to deal with) and use
rewrite_by_lua when I need more flexibility … taking care as
required.
location @pretty_urls {
rewrite_by_lua ’
if ngx.var.uri == “/sometext/xyz.html” then
return ngx.req.set_uri(“/abc.html”)
end
ngx.exec(“@proxy”);
';
}
Sorry, I’ve changed my mind and changed the ngx.req.set_uri() API a
bit in ngx_lua v0.3.1rc14. Now it’s required to trigger location jump
explicitly and the above example should be rewritten as
location @pretty_urls {
rewrite_by_lua '
if ngx.var.uri == "/sometext/xyz.html" then
-- the following function never returns
-- when the second ("jump") arg is true
ngx.req.set_uri("/abc.html", true)
end
ngx.exec("@proxy");
';
}
See the documentation here for details: Lua | NGINX
I’ve also updated the document accordingly. Sorry for the
inconvenience but I’d preserve the right to change APIs that haven’t
been in any formal releases of my modules
Thanks!
-agentzh
P.S. ngx_lua v0.3.1rc14 has already been included in ngx_openresty
devel release 1.0.8.11: OpenResty® - Open source
Unless one only jump to named locations and never to
I asked because I didn’t want to miss any quick magic