Hi,<br><br><div class="gmail_quote">On Fri, Feb 3, 2012 at 9:52 AM, Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello!<br>
<div><div class="h5"><br>
On Fri, Feb 03, 2012 at 08:53:26AM -0800, Dave Bailey wrote:<br>
<br>
> Hi,<br>
><br>
> As of nginx 1.1.6, it seems that the error_page directive can no longer be<br>
> used in a way that preserves module contexts to the log phase of the<br>
> request cycle.  This means that if I have a log handler which expects some<br>
> information that had been saved in a module context before the error_page<br>
> logic is invoked, that information is no longer accessible when the log<br>
> handler is actually called.  Is there a way to work around this?<br>
<br>
</div></div>Currently the only thing which survives internal redirects (and<br>
redirection to a named location as of 1.1.6+) is variables.  If<br>
you need something persistant, you may register one and store<br>
needed information there (up to a pointer to your module context,<br>
actually).<br></blockquote><div><br>Great, thank you.  Looks like this will work perfectly.<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

Maxim Dounin<br>
<br>
_______________________________________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
</blockquote></div><br>-dave<br><br>