question about ngx_http_named_location

[Vladimir Shebordaev]

2012/8/29 Anatoli Marinov <toli at webforge.bg>:
> "Must" is not a good reason.
> Is there a case that requires this behavior.
> In my use case I use internal redirects from location A to location @B. In
> location @B I try to read an exported variable which is actually located in

Well, module contexts are dynamic, they are created by appropriate
handlers and are destoryed when the request is terminated. An internal
redirect handled as a different request of special kind, that is why
the module contexts are (re)initialized, i.e. zeroed out as if they
were just allocated in ngx_http_init_request().

> module context and the module set this variable in location A but in @B all
> previous contexts are missing and I lost all previously set states and
> variables.

Basically, it looks like bad design, the redirect is a request on its own.

>
> Why internal redirects should erase module contexts? I think module context
> should be managed only from its module and should be attached to request
> while the request exists. Module context is the only one storage
> functionality per request and external modules depends from it. They expect
> to read exactly what was written there before.
>
> On 08/29/2012 03:47 PM, Vladimir Shebordaev wrote:
>>
>> Hi!
>>
>> 2012/8/29 Anatoli Marinov<toli at webforge.bg>:
>>
>>>
>>> Hello Mates,
>>> I am wondering why in ngx_http_named_location is used a segment of code
>>> that
>>> resets all modules contexts. I mean the line ngx_memzero(r->ctx,
>>> sizeof(void
>>> *) * ngx_http_max_module);.
>>>
>>> My opinion is that the module context should not be touched outside of
>>> the
>>> certain module. Is there a special reason for this patch? Is there a case
>>> which requires it?
>>>
>>>
>>
>> I guess, this is due to that the named location is an internal
>> redirect, so the module contexts must be reset.
>>
>>
>>>
>>> Thanks in advance
>>> Anatoli Marinov
>>>
>>>
>>>
>>