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

[lanshun zhou]

All right. We'll use $scheme://$host/error.html in http block, because we
have lots of server blocks in the deploy. Thanks.

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

> Hello!
>
> On Thu, Jan 10, 2013 at 11:57:58PM +0800, lanshun zhou wrote:
>
> > 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.
>
> No, =NNN means "I want NNN code to be returned", nothing more.  It
> allows to overwrite code returned if redirect is requested (via
> something like "http://..." set in uri parameter), but it doesn't
> request redirect by itself.
>
> > 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?
>
> Some time ago returning correct content (more specifically,
> correct type of content) in redirections was required for WAP
> phones to handle them.
>
> > 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;
> > }
>
> Use something like this instead:
>
>    error_page 404 http://example.com/error.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/20130111/35dc1d10/attachment-0001.html>