404 on a parametered route in ASP.NET Web API

[eSPiYa]

I have a parametered route, I don't know exactly what it is called generally, but instead of using query string like http://localhost:8080/api/file?appId={appId}&key={key}, we're using this http://localhost:8080/api/file/{appId}/{key}.

The ingress we created works fine on all of the Web API's endpoints but not with the parametered route. Here's the minion ingress for the service:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myservice.ingress
  namespace: myservice
  annotations:
    nginx.org/mergeable-ingress-type: "minion"
    nginx.org/rewrites: "serviceName=myservice-webapi rewrite=/"
spec:
  ingressClassName: nginx
  rules:
  - host: mydomain.com
    http:
      paths:
      - path: /serviceapi/myservice/
         pathType: Prefix
         backend:
           service:
             name: myservice-webapi
             port:
               number: 80

I can access all of the API endpoints through https://mydomain.com/serviceapi/myservice/api/ aside from the https://mydomain.com//serviceapi/myservice/api/file/{appId}/{key} which returns a 404 error. Any idea how to fix this? Thanks!

I'm trying to research about this but I'm lacking with the proper terms for this.

[j1m-ryan]

Hi @eSPiYa , we are looking into this. We have a few questions

Is the 404 coming from nginx or from the backend service?
Why is there a double slash in the URLs? eg here https://mydomain.com//
Can you post the access logs?

Thanks

[eSPiYa]

Is the 404 coming from nginx or from the backend service?

From Nginx.

Why is there a double slash in the URLs? eg here https://mydomain.com//

Sorry, it is a typo-error. I manually typed the configuration on my pc instead of my work laptop.

Can you post the access logs?

How to access it? I'm still new with Kubernetes/AKS.

[j1m-ryan]

To see the NGINX Ingress Controller logs, you need to find the pod name first.

If you deployed NGINX Ingress Controller in the default namespace, you can find the pod name with kubectl get pods
If you deployed it a different namespace like nginx-ingress you can find the pod name with kubectl get pods -n nginx-ingress

The pod name for me looks like this my-release-nginx-ingress-controller-5c4bdcc8b-gpxdf

Then after you find the pod name run kubectl logs -f <podname> and if you have it deployed in a different namespace include -n <namespace>
Then you should see the logs.

I deployed a similar example to you, slightly modifying the example here. https://github.com/nginxinc/kubernetes-ingress/tree/main/examples/ingress-resources/mergeable-ingress-types.
The only part I changed was the minion ingress, where I added in the nginx.org/rewrites annotation that you have, and the path that you have.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress-coffee-minion
  annotations:
    nginx.org/mergeable-ingress-type: "minion"
    nginx.org/rewrites: "serviceName=coffee-svc rewrite=/"
spec:
  ingressClassName: nginx
  rules:
  - host: cafe.example.com
    http:
      paths:
      - path: /serviceapi/myservice/
        pathType: Prefix
        backend:
          service:
            name: coffee-svc
            port:
              number: 80

First I sent a request to the path itself
curl -k https://cafe.example.com/serviceapi/myservice/

This was the response

Server address: 10.244.0.4:8080
Server name: coffee-56b44d4c55-msxfr
Date: 31/Jul/2024:11:04:18 +0000
URI: /
Request ID: 3f957a09313b976d6d771a13dad25e69

and the NGINX Ingress Controller logs show a 200

10.244.0.1 - - [31/Jul/2024:11:04:18 +0000] "GET /serviceapi/myservice/ HTTP/1.1" 200 154 "-" "curl/8.6.0" "-"

Then I sent a request to cafe.example.com/serviceapi/myservice/api/file/id-1/key-2/ with the command
curl -k https://cafe.example.com/serviceapi/myservice/api/file/id-1/key-2/

This was the response

Server address: 10.244.0.7:8080
Server name: coffee-56b44d4c55-lzd8d
Date: 31/Jul/2024:11:07:57 +0000
URI: /api/file/id-1/key-2/
Request ID: a2c70e96bd7f553f804d3cab3838d3cd

and again NGINX Ingress Controller shows a 200

10.244.0.1 - - [31/Jul/2024:11:07:57 +0000] "GET /serviceapi/myservice/api/file/id-1/key-2/ HTTP/1.1" 200 174 "-" "curl/8.6.0" "-"

This is the expected behaviour, the matched path/serviceapi/myservice/ is stripped from the request before it goes to the upstream, becuase of the rewrite annotation to /

The 404 you receive from a GET request to /api/file/id-1/key-2/ might be determined by how your backend service handles this path, rather than by NGINX itself.
If you're still stuck, post the logs here and we'll take a look.

[eSPiYa]

It suddenly worked without changing anything. thanks!

[j1m-ryan]

Ah ok. Glad to hear you got it sorted!