[PATCH] Honor the redirect response overwritten in error_page for absolute urls

[lanshun zhou]

Yeah, this will break current supported configs like the one you provided.
But only
the ones with 30x response code overwritten and without named location are
affected. I think =30x in error_page is something like the "redirect" flag
in "rewrite",
which means "I want the redirect" by default.

I could think of these kinds of configs broken before the patch, and
just not sure
why introducing a location for 30x response.  Is the content
for 30x response
valuable? or to generate the "Location" header dynamically which can not be
expressed by the url param with variables supported?

But this patch does break supported configs, although named locations
can be used
instead as before to do anything. I just don't l like introducing a
location to redirect
for 404 error_page :)

error_page 404 @notfound;

location @notfound {
    return 302 /error.html;  # or rewrite ^ /error.html redirect;
}

2013/1/10 Maxim Dounin <mdounin at mdounin.ru>

> Hello!
>
> On Thu, Jan 10, 2013 at 07:31:07PM +0800, lanshun zhou wrote:
>
> > Absolute url in error_page is always treated by an internal redirect,
> even
> > if the response
> > code is specified with 301/302. This patch honors the response code
> > specified and
> > makes it possible to redirect with absolute url in error_page easily.
>
> I don't like this change.  Current behaviour is well-defined and
> allows to do anything (with an additional step in some case).  On
> the other hand, introducing logic which takes new response code
> into account will complicate things.  The difference between these
> two lines will be counterintuitive:
>
>     error_page 301 /foo.html;
>     error_page 301 =302 /foo.html;
>
> Additionally, it will break configs like this:
>
>     error_page 301 =302 /foo.html;
>
>     location = /foo.html {
>         ...
>     }
>
> (I.e. change the response code and return content from the
> "/foo.html".)
>
> --
> Maxim Dounin
> http://nginx.com/support.html
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20130110/76bc396c/attachment.html>