error_page behavior

[B.R.]

Whoops!
Minimal test configuration FTW... There was a '/' prefix location block
hidden at the bottow of my server one, with an ugly 'try_files $uri.php
=404;' directive...

As notes, though :

I removed the '=' parameter from the error_page directive to simplify, as
there is no special processing during error handling.
I forgot to update the configuration snippet in the mail.

Let's be clear about proxy_intercept_errors:
Setting it to 'on' enables error processing through error_page.
The default (off) simply propagates the proxy error (status code >= 300) to
clients.

I should have double/triple/quadruplechecked the configuration before
writing on this ML.
​Thanks for your time Francis! And sorry about that...​
---
*B. R.*

On Mon, Apr 4, 2016 at 10:12 PM, Francis Daly <francis at daoine.org> wrote:

> On Mon, Apr 04, 2016 at 08:54:12PM +0100, Francis Daly wrote:
> > On Mon, Apr 04, 2016 at 09:36:36PM +0200, B.R. wrote:
>
> Hi there,
>
> > > -> Error page HTTP 404 (???)
> >
> > I only get 404 if error_page.html does not exist. If it does exist,
> > I get it with http 200.
> >
> > Aside from that: I suspect that proxy_intercept_errors does exactly the
> > opposite of what you think it does.
>
> Apologies - I was wrong there.
>
> "proxy_intercept_errors on;" means that error_page *is* used for the
> returned http status.
>
> "proxy_intercept_errors off;" means that it is not, and the full original
> status+body gets to the client.
>
> So you had (and have) it the way that you want it to be.
>
>         f
> --
> Francis Daly        francis at daoine.org
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160404/e3ef2941/attachment.html>