Path based routing is not working on contour

[rshiva777]

What steps did you take and what happened: [A clear and concise description of what the bug is.]

Deployed multiple nginx applications and tried to access it using httpproxy with path based routing

What did you expect to happen: Path based routing should work

Anything else you would like to add: [Miscellaneous information that will assist in solving the issue.]

I tried to configure multiple apps, one with the root prefix, and the other one with /blog prefix. The root prefix seems to be working fine, but the /blog prefix is not working.

Envoy log: when i access the / prefix: [2022-07-20T11:05:21.955Z] "GET / HTTP/1.1" 304 - 0 0 1 1 "10.96.4.1" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36" "7bd0e9b1-a441-4f50-975f-5eb2f2afv557" "nginx.test.com" "10.96.0.31:80"

when i access the /blog prefix: [2022-07-20T11:05:27.032Z] "GET /grafana/api/live/ws HTTP/1.1" 403 - 0 0 0 - "10.96.4.1" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36" "c5s4049c-49c4-4137-8ae9-43d4t6caecaa" "nginx.test.com" "-"

Httpproxy yaml: `apiVersion: projectcontour.io/v1 kind: HTTPProxy metadata: name: multiple-paths namespace: default spec: routes:

• conditions:

  • prefix: / services:
  • name: nginx port: 80

• conditions:

  • prefix: /blog services:
  • name: nginxnew port: 80 virtualhost: fqdn: nginx.test.com ` Environment:

• Contour version: v1.12.0

• Kubernetes version: (use kubectl version): 1.21

• Kubernetes installer & version: 1.21

• Cloud provider or hardware configuration: vmware

• OS (e.g. from /etc/os-release): ubuntu

[youngnick]

Hi @rshiva777, did you check that your app is configured to accept requests at /blog? Contour does not strip the matched path, so the requests that arrive at the backend pods will be http://nginx.test.com/blog/<path>, not http://nginx.test.com/<path>.

If you are wanting the latter, you will probably need to configure path rewriting to remove the matched path, see https://projectcontour.io/docs/v1.21.1/config/request-rewriting/#path-rewriting for more details.

[rshiva777]

@youngnick Thanks for the inputs. I am able to get succeed by adding the below ingress:

apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
  name: nginx
  namespace: default
spec:
  routes:
  - conditions:
    - prefix: /nginx01
    pathRewritePolicy:
      replacePrefix:
      - prefix: /nginx01
        replacement: /
    services:
    - name: nginx01
      port: 80
  virtualhost:
    fqdn: nginx.test.com

However if i deleted the httpproxy resource, still i am able to reach the service from fqdn. Not sure why this is happening. Could you please update on this. Moreover i dont see any logs on envoy

Actual result: If i remove the httpproxy resource, the fqdn is still reaching the destination service

Expected result: If i remove the httpproxy resource, the fqdn should not reach the destination service

[rshiva777]

I tried to clear browsing history, cache from browser, even though no lucky

[rshiva777]

Adding test result:

1. i removed the entire deployment and httproxy of nginx, even then i am able to get nginx page with fqdn on browser
2. I have given same nginx fqdn to other application to verify if the nginx page with change to application page. Even then when i hit fqdn is showing nginx page

Not sure when the data is getting cached. It always trying to point nginx web page, even the application/httpproxy for nginx is not running on the cluster

[tsaarni]

Did you check with something that does not cache, curl for example? Can this be also related to #4641 where you mentioned that Envoy logs are missing? The logs would be missing if the request is somehow served by something else, such as cache.

[rshiva777]

@tsaarni

1. I am able to get succeed by using curl with fqdn. It is hitting my application (curl is hitting the new application)

2, If i try it access from browser, it is hitting to nginx service again. I tried clearing full broswing history/cache. even then facing same issue

Not showing any logs on the contour envoy. This fqdn is not used anywhere but it is resolving.

[tsaarni]

It is bit difficult for me to understand what is going on with the deployment, since it seems like something else serves the requests - if I understood you correctly, there is success responses even when the application is not deployed 🤔. In the description of this issue you gave some Envoy logs. Is it so that the requests get logged by Envoy when you had HTTPProxy instance created but when you remove the instance and even removed the application itself, you still get success responses but no Envoy logs?

Have you checked the application logs for any clues which backend actually gets the requests and where the requests originate?

[rshiva777]

@tsaarni sorry for the delay as i was on long leave.

Please find the below inputs:

1. This issue happen only when i deployed nginx app and expose fqdn and then delete pod/httpproxy. even then fqdn is accessible. No logs are generated on the envoy. even application is deleted but still accessible over fqdn. i removed cache no use

• if i try to deploy other application using same fqdn with /test prefix, it is resolving and showing nginx webpage again.

2. When i deploy other app other than nginx with different fqdn which was not used in step 1, its working as expected. if i delete fqdn, it is not resolving.

Issue occur only for nginx application, not sure what is causing the issue.

[github-actions[bot]]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[github-actions[bot]]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack