Note: You need to explicitly define the error_page handler for this for
it
to be useful. As Igor says, “nginx does not intercept an error if there
is
no custom handler for it it does not show its default pages. This allows
to
intercept some errors, while passing others as are.”
Actually I still can’t understand the exact meaning, so I have done some
experimentd.
turn on fastcgi_intercept_errors,
in the backend php/fcgi send 404 header,
set the error_page (php)
Result: nginx use the default error template
turn off fastcgi_intercept_errors,
in the backend php/fcgi send 404 header
set the error_page (php)
Result: now the custom error_page (php) is being used.
So it seems to me that* fastcgi_intercept_errors should be off and set
the error_page *if I need to specify custom error handler, is
this interoperation correct?
On Tue, Nov 06, 2012 at 01:12:05AM +0800, howard chen wrote:
Result: now the custom error_page (php) is being used.
It’s unclear how you did your experiments, but results
are all wrong - most likely, you missed something.
E.g. in (1) I would assume request to the error_page resulted in
another 404, which in turn resulted in default error page
returned.
So it seems to me that* fastcgi_intercept_errors should be off and set
the error_page *if I need to specify custom error handler, is
this interoperation correct?
No.
The fastcgi_intercept_errors directive is off by default, and this
means that nginx won’t try to do anything with responses returned
by backends as long as they are valid.
If you want nginx to change response returned by a backend, you
have to switch on fastcgi_intercept_errors and configure
appropriate error_page. Example configuration: