Hello!
On Tue, Dec 20, 2022 at 11:44:05PM +0530, Kaushal Shriyan wrote:
> On Sat, Dec 17, 2022 at 3:48 AM Maxim Dounin <mdounin@mdounin.ru> wrote:
>
> > On Fri, Dec 16, 2022 at 11:53:40PM +0530, Kaushal Shriyan wrote:
> >
> > > I have a follow up question regarding the settings below in nginx.conf
> > > where the php-fpm upstream server is processing all php files for Drupal
> > > CMS.
> > >
> > > fastcgi_intercept_errors off
> > > proxy_intercept_errors off
> > >
> > > User -> Nginx -> php-fpm -> MySQL DB.
> > >
> > > For example if the php-fpm upstream server is down then nginx should
> > render
> > > 502 bad gateway
> > > if MySQL DB service is down then nginx should render
> > > 500 ISE.
> > >
> > > Is there a way to render any of the messages or any custom messages to
> > the
> > > User from the php-fpm upstream server that should be passed to a client
> > > without being intercepted by the Nginx web server. Any examples? I have
> > > attached the file for your reference. Please guide me. Thanks in advance.
> >
> > Not sure I understand what are you asking about.
> >
> > With fastcgi_intercept_errors turned off (the default) nginx does
> > not intercept any of the errors returned by php-fpm.
> >
> > That is, when MySQL is down and php-fpm returns 500 (Internal
> > Server Error), it is returned directory to the client. When
> > php-fpm is down, nginx generates 502 (Bad Gateway) itself and
> > returns it to the client.
> >
> >
> Hi Maxim,
>
> Apologies for the delay in responding. I am still not able to get it. The
> below settings will be hardcoded in nginx.conf. Is there a way to
> dynamically render the different errors to the client when the client hits
> http://mydomain.com/apis
>
> error_page 502 /502.json;
>
> location = /502.json {
> return 200 '{"errors": {"status_code": 502, "status": "php-fpm
> server is down"}}';
> }
>
> Please guide me. Thanks in advance.
You can pass these error pages to a backend server by using
proxy_pass or fastcgi_pass in the location, much like any other
resource in nginx.
Note though that in most cases it's a bad idea, at least unless
you have a dedicated backend to generate error pages: if a request
to an upstream server failed, there is a good chance that another
request to generate an error page will fail as well.
As such, it is usually recommended to keep error pages served by
nginx itself, either as static files, or directly returned with
"return".
--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list
nginx@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx
