Ingress-nginx: wrong approach in rewrite+add-base-url ?

Created on 19 Dec 2016  路  9Comments  路  Source: kubernetes/ingress-nginx

Moved this here from contrib.

Maybe I'm getting this wrong, but the base-url should be constructed from matched path instead of rewrite target.

Problem description:

Ingress rule:

path = "/p"
rewrite-target = "/"
add-base-url = true

How it works:

base-url=protocol://host/target => http(s)://some.host/
  • css/test.css becomes http(s)://some.host/css/test.css (ingress rule is not matched anymore)

How it should work:

base-url=protocol://host/target => http(s)://some.host/p
  • css/test.css becomes http(s)://some.host/p/css/test.css (matches the ingress rule and URL is rewritten to /css/test.css for the backend to be loaded correctly)

If a path "/p" is matched by the ingress rule, the backend is rewritten to /, but the resources should still be pulled by /p/ from the browser point of view, otherwise there is no matching path in ingress rule.

lifecyclrotten

Most helpful comment

What is the status of the issue? Because indeed, the base tag doesn't contains the application path set in the ingress...
Is there a workaround?

All 9 comments

I don't understand this either. The nginx template file doesn't seem to make use of the Target or AddBaseURL fields of the struct decoded from the annotations aside from disabling compression when AddBaseURL is true...

gcr.io/google_containers/nginx-ingress-controller makes rewrite as following:
rewrite /studio-test/(.*) /studio/$1 break;
But it should be
rewrite /studio-test(.*) /studio$1 break;

Here is my Ingress resource

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    ingress.kubernetes.io/rewrite-target: /studio
  name: studio-test
spec:
  rules:
  - host: test.dom.net
    http:
      paths:
      - path: /studio-test
        backend:
          serviceName: studio
          servicePort: 80

What is the status of the issue? Because indeed, the base tag doesn't contains the application path set in the ingress...
Is there a workaround?

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

/reopen

@navi86: you can't re-open an issue/PR unless you authored it or you are assigned to it.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

kfox1111 picture kfox1111  路  3Comments

smeruelo picture smeruelo  路  3Comments

geek876 picture geek876  路  3Comments

silasbw picture silasbw  路  3Comments

c-mccutcheon picture c-mccutcheon  路  3Comments