Ingress rewrite string is being ignored

The requirement is to access the burger service in https://meals.food.com/burger2. The context path within the app is /burger.

Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /burger/$2
spec:
  rules:
  - host: meals.food.com
    http:
      paths:
      - backend:
          service:
            name: burger
            port:
              number: 80
        path: /burger2(/|$)(.*)
        pathType: Prefix

Upon checking the ingress controller logs:

[05/Jan/2022:13:54:11 +0000] "GET // HTTP/1.1" 304 0 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36" 957 0.002 [anotherservice-80] [] x.x.x.x:80 0 0.002 304 230200x023

Is my ingress config correct? My suspicion is that something is altering the request between my request from the browser to ingress-controller.

Solution

Is my ingress config correct? My suspicion is that something is altering the request between my request from the browser to ingress-controller.

Your ingress config looks OK. I do not see any errors in it. He will act as follows: The example address meals.food.com/burger2/blah-blah-blah will be rewirted to meals.food.com/burger/blah-blah-blah. If that was your intention then config is fine.

However you have got 304 HTTP code.

The HTTP 304 Not Modified client redirection response code indicates that there is no need to retransmit the requested resources. It is an implicit redirection to a cached resource. This happens when the request method is safe, like a GET or a HEAD request, or when the request is conditional and uses a If-None-Match or a If-Modified-Since header.

The equivalent 200 OK response would have included the headers Cache-Control, Content-Location, Date, ETag, Expires, and Vary.

In other words When the browser receives a request, but does not know whether it has the latest version of a write, it sends a conditional validation request, communicating the last modified date and time to the server via the If-Modified-Since or If-None-Match header.

The server then checks these headers and determines if their values are the same. If so - the server will send back the HTTP 304 code and the browser will use the cached copy of the resource. If not, it means that the file has been modified, so the browser will save a new copy by sending HTTP 200 code.

In your case it looks as if someone tried to download the same (unchanged) resource multiple times and therefore got the code 304. If so, everything is fine.