nginx returns html instead of json response

Kaushal Shriyan kaushalshriyan at gmail.com
Fri Nov 18 13:37:41 UTC 2022


On Thu, Nov 17, 2022 at 10:57 PM Francis Daly <francis at daoine.org> wrote:

> On Mon, Nov 14, 2022 at 08:24:15PM +0530, Kaushal Shriyan wrote:
> > > On Fri, Nov 11, 2022 at 2:38 PM Francis Daly <francis at daoine.org>
> wrote:
>
> Hi there,
>
> > >> What one specific request do you want to make? (Maybe
> > >> http://mydomain.com/apis, maybe http://mydomain.com/api/v1/*, maybe
> > >> http://mydomain.com/api/v1/example, maybe something else?)
> > >>
> > >> For that one specific request, what do you want nginx to do with
> > >> it? (Maybe make a http request to the Drupal system? Or a fastcgi
> request
> > >> to the Drupal system? Or handle it internally withint nginx?)
> > >>
> > >> For the response from that request, what do you want nginx to do with
> > >> it? (Send it to the user as-is? Mangle / modify it somehow? If so --
> > >> how? Change the http response code or headers? Change the response
> body?)
>
> > So I think, if somehow we can pass the information to Nginx to not take
> any
> > action if 500 error occurred while hitting the
> > https://mydrupalsite.com/apis or
> https://mydrupalsite.com/apis/uinque_id
> >  URLs then our job will done, because in that case whatever Drupal is
> > sending we will be able to see that if 500 error occurred.
>
> Correct.
>
> You will want a location{} to handle the "api" requests; and in that
> location, do not have the inherited "error_page 500" directive take effect.
>
> I think that you cannot "undo" an error_page directive from a previous
> level, but you can set a "dummy" error_page directive which will have
> the effect of overriding any values set at a previous level. So --
> pick a http response code that you do not care about (e.g. 555) and set
> error_page for that in this location.
>
>
> From your config, it looks like there are three forms of "non-api"
> requests that matter:
>
> * /one/file.html - which will return the local file
> /var/www/html/gsmamarketplace/web/one/file.html
>
> * /two/file.php - which will ask drupal to use the local file
> /var/www/html/gsmamarketplace/web/two/file.php
>
> * /three/not-a-file - which will ask drupal to use the local file
> /var/www/html/gsmamarketplace/web/index.php
>
>
> What forms of "api" request do you expect to receive? And what,
> specifically, do you want nginx to do with each form?
>
> That is -- do you expect "/apis/one/file.html", or "/apis/two/file.php",
> or "/apis/three/not-a-file", or some of each, or something else?
>
> When the request is for "/apis/unique_id", what file on the filesystem
> do you want nginx to serve; or what file on the filesystem do you want
> nginx to ask drupal to use?
>
> Cheers,
>
>         f
> --
> Francis Daly        francis at daoine.org
> _______________________________________________
> nginx mailing list -- nginx at nginx.org
> To unsubscribe send an email to nginx-leave at nginx.org



Thanks Francis for the detailed explanation.

Overriding the nginx 500 error message will not be a solution for us as we
are handling 500 errors in Drupal codebase, and 500 errors can occur in any
file of the codebase, at code level we are handling that and sending the
json response. So incase of, ' /apis ' call or .'apis/unique_id' call if
nginx web server does nothing, then by default the JSON response whatever
Drupal CMS (https://www.drupal.org/) sends will be displayed to the user
and this will solve our problem.

We can not have a dedicated page (either php or html) to display the
response as 500 error messages can occur from any random file of the
codebase. Whenever the 500 error occurs, Drupal CMS (https://www.drupal.org/)
will return a JSON response and that JSON response content can be different
based on the cause of the issue.

For example https://mydrupalsite.com/apis and
https://mydrupalsite.com/apis/uinque_id for these two page hits, even if
500 error occurred we do not want nginx to show the default HTML 500 error
page. In short we want nginx webserver to do nothing and not consider these
two pages while showing 500 errors.

Please let me know if you need any additional information and I look
forward to hearing from you. Thanks in advance.

Best Regards,

Kaushal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20221118/2c305323/attachment.htm>


More information about the nginx mailing list