Hi,
I will appreciate if someone can pitch in for my earlier post to this
mailing list. I have the below location block.
location /apis {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
fastcgi_intercept_errors off;
add_header "X-Debug-JSON-APIS" $upstream_http_content_type"abc" always;
default_type application/json;
return 500 '{"errors": "MySQL DB Server is down"}';
# if ($isdatatypejson = "no") {
# add_header 'Content-Type' 'application/json' always;
# add_header 'Content-Type-2'
$upstream_http_content_type$isdatatypejson"OK" always;
# return 502 '{"errors": {"status_code": 502,"status":
"php-fpm server is down"}}';
# }
When I hit http://mydomain.com/apis for conditions when MySQL DB is down. I
get the below output and it works as expected.
{"errors": "MySQL DB Server is down"}
When I hit http://mydomain.com/apis for conditions when MySQL DB is up and
running fine, I get the below output in spite of MySQL DB server being
fine.
{"errors": "MySQL DB Server is down"}
Ideally the application will be working as normal. Am I missing anything
in the nginx config? I have tested using the attached nginx.conf file for
your reference. Please suggest.
Thanks in advance.
Best Regards,
Kaushal
On Wed, Jan 4, 2023 at 10:53 PM Kaushal Shriyan <kaushalshriyan@gmail.com>
wrote:
> Hi Maxim,
>
> I have tested using the attached nginx.conf file for your reference. I
> tested using both scenarios.
>
> When MySQL DB is down it works as expected.
>
> {"errors": "MySQL DB Server is down"}
>
> MySQL DB is up and running
>
> It reports {"errors": "MySQL DB Server is down"} in spite of MySQL DB
> server being fine.
>
> Please suggest. Thanks in advance.
>
> Best Regards,
>
> Kaushal
>
>
> On Thu, Dec 22, 2022 at 7:04 AM Maxim Dounin <mdounin@mdounin.ru> wrote:
>
>> 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
>>
>
_______________________________________________
nginx mailing list
nginx@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx
