Score:0

{“status”:400,“message”:“Bad request”} when hit a microservice using Nginx API Gateway

us flag

Hi I am trying to consume an api using Nginx API Gateway: I have this url: example.com/api/nodeapp. In my setup I have an Ingress controller which is exposed externally at .com and which takes request do oauth and redirect to internal nginx pod(exposed as Cluster IP service in private cluster) this internal nginx pod will do re route to target microservice pod (also exposed as Cluster IP service in same private cluster). Goal: I browse url as example.com/api/nodeapp ---> the Ingress will do oauth and redirect request to Nginx (which is happening fine ) the Nginx take my request and redirect me to target nodeapp microservice (which is failing at Error 400) My code snippets:

Ingress.yaml

spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /api/nodeapp
            backend:
              serviceName: nginx-internal-service
              servicePort: 80
          - path: /api/tea
            backend:
              serviceName: nginx-internal-service
              servicePort: 80

Nginx.conf

user  nginx;
worker_processes  auto;

error_log  /var/log/nginx/error.log debug;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;
    include /etc/nginx/api_gateway.conf;
    include /etc/nginx/conf.d/*.conf;
}

api_gateway.conf

include api_backends.conf;
#include api_keys.conf;

server {
    access_log /var/log/nginx/api_access.log main; # Each API may also log to a separate file

    listen 80; # TLS config goes here (for production use)
    server_name example.com;

    # TLS config
    #ssl_certificate      /etc/ssl/certs/api.example.com.crt;
    #ssl_certificate_key  /etc/ssl/private/api.example.com.key;
    #ssl_session_cache    shared:SSL:10m;
    #ssl_session_timeout  5m;
    #ssl_ciphers          HIGH:!aNULL:!MD5;
    #ssl_protocols        TLSv1.2 TLSv1.3;
   # Invalid resource
    location / {
        rewrite ^ https://$host$request_uri permanent;
    }
    # API definitions, one per file
    include api_conf.d/*.conf;

    # Error responses
    error_page 404 = @400;         # Invalid paths are treated as bad requests
    location @400 {
        return 400 '{"status":400,"message":"Bad request"}\n';
    }
    proxy_intercept_errors on;     # Do not send backend errors to the client
    include errors_json.conf;  # API client friendly JSON error responses
    default_type application/json; # If no content-type then assume JSON
}

nodeapi_simple.conf

# Node API
#
location /api/ {
    # Policy configuration here (authentication, rate limiting, logging, more...)
    #
    access_log /var/log/nginx/nodeapp_api.log main;

    # URI routing
    #
    location /api/tea {
        proxy_pass http://tea;
    }

    location /api/nodeapp {
        proxy_pass http://nodeapp;
    }

    return 404; # Catch-all
}

# vim: syntax=nginx

api_backend.conf

upstream nodeapp {
    zone nodeapp 64k;
    server nodeapp IP:8000;
    
    
}


upstream tea {
    zone tea 64k;
    server Tea app IP:80;
    
    
}



# vim: syntax=nginx

My main focus here is to run the example.com/api/nodeapp to run which is not working though I have already tested nodeapp on localhost its running fine. Also strange thing is this tea app is a just a sample text based app which is working as I hit in the browser with URL example.com/api/tea its working a[[1]: https://i.stack.imgur.com/3fP3k.png][1]s per below snap:

Here are my logs [1]: https://i.stack.imgur.com/jssnb.png][1] I been stuck on this error since 3 days hence requesting everyone to help me out on this at their earliest conveniences

Michael Hampton avatar
cz flag
Did you write this nginx configuration or copy it from somewhere? It clearly shows that the "400" you got was actually a 404 from the API server that your configuration rewrites to a 400 with that specific response body. You should be looking at the API server next.
yash avatar
us flag
I use the nginx configuration from nginx blog "Deploying NGINX as an API Gateway, Part 1" and I tested the node api server with external nginx ingress itself it was hitting fine (200) like whenever i hit example.com/node (without use of internal nginx) i get the page successfully but when I hit example.com/api/nodeapp(via ingress and internal nginx pod) i am getting this 400 error
yash avatar
us flag
I have added logs as well though they are not much in details but this is what I am only getting
yash avatar
us flag
you are right I commented the line "error page 404 = @400 " and now i am getting error 404 but not sure what to do next
Michael Hampton avatar
cz flag
You check your application, again.
yash avatar
us flag
I rechecked my application inside the server its working actually there is one catch here there is something wrong with " proxy pass http://nodeip:nodeport" What I did is I commented this line in the location /api/nodeapp {) block and instead that I put return 200; and then tested my app it was hitting at 200 which means that there is something fishy with proxy pass that is unable to hit my node app
yash avatar
us flag
Its working i guess now I just need to add / at the end of proxy pass proxy pass nodeip:nodeport like this --> proxy pass nodeip:nodeport/
yash avatar
us flag
The one issue it had how if my application is configured in such a way that my request could be like /api/nodeapp/something then how to redirect this url to the targeted page ?
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.