Rancher nginx-ingress url rewrite not working as expected

General Discussions
1

@aledbf
Our admin informed me that we are running following nginx-ingress on our rancher kubernetes cluster: rancher/nginx-ingress-controller:0.16.2-rancher1 So i am not sure what native ingress-nginx version it is using.
We get strange behavior for the url rewrite that parts of the url are repeated.

Our ingress rule with the test results:

ingress1
ingress1.PNG771×920 46.1 KB

If i do the same as in the documentation of https://kubernetes.github.io/ingress-nginx/examples/rewrite/ but with an nginx-alpine i have following behavior seen in the nginx log. I mention rewrite.bar.com here to compare it to the example more easily. I tested it with my specific host name.

2

@stebo just use a at symbol and tag aledbf

3

@stebo the link of the documentation is for the latest version (0.22.0). Keep in mind the latest version introduced a change in the rewrite-target annotation not compatible with the previous versions
To know what version are you running exactly, you need to check the ingress controller pod log. At the start you will see something like:

-------------------------------------------------------------------------------
NGINX Ingress controller
  Release:    0.22.0
  Build:      git-f7c42b78a
  Repository: https://github.com/kubernetes/ingress-nginx
-------------------------------------------------------------------------------
4

Hi @aledbf ,

I checked with our admin to ask what version we had and added what you asked. And now his reply is that he upgraded to version 0.22. I retested and now the test with the alpine nginx request looks ok in the logs. But i test that with non existing url paths causing a 404.

When I test it with a not existing url on our API, it seems it strips of perfect the date part.

but when i enter then a valid one, the url gets redirected to a url without the date part and i endup with a location that is not valid anymore. Do you think that the redirect is coming from the url rewrite or does it might be a behavior of the API ?

image
image.png771×379 94.2 KB

The intention is that the url with the date part stays in the url, but that the upstream only gets the part without the date. The wanted behavior is described here : https://www.getambassador.io/reference/rewrites/

Regards,
Steven

5

@stebo you are missing the final s in the first screenshot. Also, that error is returned by your application, not the ingress controller, so the rewrite is working

6

@stebo also, the second screenshot is correct if you don’t have /API as a path in the ingress rule

7

yes the missing s is intentionally done to get the error page of the API, to see what is send to the API of url

8

and the url http://logixdevhist.gem.myengie.com/API/contracts/ i didn’t type in manually. That came automatically after i entered http://logixdevhist.gem.myengie.com/20190220/API/contracts/
But when i try it now again, it seems to be working ???

9

@stebo keep in mind the rewrite feature works when a client make a request to the ingress controller. If your application returns a redirect (just as an example) to /API/contracts/..... then you will get a 404 from the ingress controller. There is no rewrite of the content returned from your application.

You can do that using something like:

nginx.ingress.kubernetes.io/configuration-snippet: |
  sub_filter '/API/contracts/' '/20190220/API/contracts/';

Keep in mind that will work but impacts the performance. This can be avoided if you can return relative links.

10

@aledbf
I would never want to do the

sub_filter ‘/API/contracts/’ ‘/20190220/API/contracts/’;

Only rewriting from location /20190220 needs to happen. I don’t know what caused the automatic browser redirect from http://logixdevhist.gem.myengie.com/20190220/API/contracts/ into http://logixdevhist.gem.myengie.com/API/contracts/ the first time