On 15 October 2011 13:07, agentzh <agentzh@gmail.com> wrote:
> On Sat, Oct 15, 2011 at 5:57 PM, Nginx User <nginx@nginxuser.net> wrote:
>> All in all, I have come to realise that ngx_lua is slightly evil in
>> that unexpected things can happen. As with "if" however, evil
>> understood is evil avoided :-)
>>
>
> The ngx_lua module won't play seamlessly with ngx_rewrite because
> ngx_rewrite does use internal hacks and tricks to make things work. So
> I'd recommend use Lua to do as much as possible and avoid using
> ngx_rewrite's directives but simple "set".
>
Would it mean "if" blocks? The last, redirect, permanent etc flags
available to rewrite are very convenient.

>> Any thoughts on Marcus' points earlier on clearing the ctx in the core?
>
> Well, there're indeed cases that we do want to retain module contexts
> during a jump but I've already managed to "abuse" the post_subrequest
> mechanism to save the pointer to my module's context and later restore
> it in my output header filter, for example. (See how I do this in my
> ngx_lua module for ngx.location.capture.)
>
> But on the other hand, if I do want to clear my module's context
> before a internal redirection, then there's no easy way to do that
> myself.
>
>> Seems to suggest that may cause problems elsewhere and that it is
>> better to be handled at the module level.
>
> No, this is impossible to handle that fully on the module level. For
> example, if you do use ngx_upload module's upload_pass instead of
> ngx_lua or ngx_echo to do the jump, then it'll still break
> rewrite_by_lua and access_by_lua (at least).
>
>> Seems logical as whether it was originally an oversight or not,
>> 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.

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx