2018-10-01 17:54:11 +00:00
# Ingress Path Matching
## Regular Expression Support
2019-12-12 23:12:12 +00:00
!!! important
Regular expressions and wild cards are not supported in the `spec.rules.host` field. Full hostnames must be used.
2018-12-18 17:53:54 +00:00
2018-10-04 14:58:38 +00:00
The ingress controller supports **case insensitive** regular expressions in the `spec.rules.http.paths.path` field.
2019-06-05 01:14:50 +00:00
This can be enabled by setting the `nginx.ingress.kubernetes.io/use-regex` annotation to `true` (the default is false).
2018-10-01 17:54:11 +00:00
2018-10-12 01:09:01 +00:00
See the [description ](./nginx-configuration/annotations.md#use-regex ) of the `use-regex` annotation for more details.
2018-10-01 17:54:11 +00:00
2018-10-12 01:09:01 +00:00
```yaml
2019-12-12 23:12:12 +00:00
apiVersion: networking.k8s.io/v1beta1
2018-10-01 17:54:11 +00:00
kind: Ingress
metadata:
name: test-ingress
annotations:
2018-10-19 03:44:45 +00:00
nginx.ingress.kubernetes.io/use-regex: "true"
2018-10-01 17:54:11 +00:00
spec:
rules:
2018-10-19 03:44:45 +00:00
- host: test.com
http:
paths:
- path: /foo/.*
backend:
serviceName: test
servicePort: 80
2018-10-01 17:54:11 +00:00
```
The preceding ingress definition would translate to the following location block within the NGINX configuration for the `test.com` server:
2018-10-12 01:09:01 +00:00
```txt
2018-10-19 03:44:45 +00:00
location ~* "^/foo/.*" {
2018-10-01 17:54:11 +00:00
...
}
```
## Path Priority
2018-11-10 11:33:51 +00:00
In NGINX, regular expressions follow a **first match** policy. In order to enable more accurate path matching, ingress-nginx first orders the paths by descending length before writing them to the NGINX template as location blocks.
2018-10-01 17:54:11 +00:00
2018-10-12 01:09:01 +00:00
**Please read the [warning ](#warning ) before using regular expressions in your ingress definitions.**
2018-10-01 17:54:11 +00:00
### Example
Let the following two ingress definitions be created:
2018-10-12 01:09:01 +00:00
```yaml
2019-12-12 23:12:12 +00:00
apiVersion: networking.k8s.io/v1beta1
2018-10-01 17:54:11 +00:00
kind: Ingress
metadata:
name: test-ingress-1
spec:
rules:
2018-10-19 03:44:45 +00:00
- host: test.com
http:
paths:
- path: /foo/bar
backend:
2018-12-13 18:02:05 +00:00
serviceName: service1
2018-10-19 03:44:45 +00:00
servicePort: 80
- path: /foo/bar/
backend:
2018-12-13 18:02:05 +00:00
serviceName: service2
2018-10-19 03:44:45 +00:00
servicePort: 80
2018-10-01 17:54:11 +00:00
```
2018-10-12 01:09:01 +00:00
```yaml
2019-12-12 23:12:12 +00:00
apiVersion: networking.k8s.io/v1beta1
2018-10-01 17:54:11 +00:00
kind: Ingress
metadata:
name: test-ingress-2
annotations:
2019-02-06 15:48:08 +00:00
nginx.ingress.kubernetes.io/rewrite-target: /$1
2018-10-01 17:54:11 +00:00
spec:
rules:
2018-10-19 03:44:45 +00:00
- host: test.com
http:
paths:
2019-02-06 15:48:08 +00:00
- path: /foo/bar/(.+)
2018-10-19 03:44:45 +00:00
backend:
2018-12-13 18:02:05 +00:00
serviceName: service3
2018-10-19 03:44:45 +00:00
servicePort: 80
2018-10-01 17:54:11 +00:00
```
2018-10-12 01:09:01 +00:00
The ingress controller would define the following location blocks, in order of descending length, within the NGINX template for the `test.com` server:
2018-10-01 17:54:11 +00:00
2018-10-12 01:09:01 +00:00
```txt
2018-12-13 18:02:05 +00:00
location ~* ^/foo/bar/.+ {
2018-10-01 17:54:11 +00:00
...
}
2018-10-19 03:44:45 +00:00
location ~* "^/foo/bar/" {
2018-10-01 17:54:11 +00:00
...
}
2018-10-19 03:44:45 +00:00
location ~* "^/foo/bar" {
2018-10-01 17:54:11 +00:00
...
}
```
2018-10-12 01:09:01 +00:00
2018-10-01 17:54:11 +00:00
The following request URI's would match the corresponding location blocks:
2018-10-12 01:09:01 +00:00
2018-12-13 18:02:05 +00:00
- `test.com/foo/bar/1` matches `~* ^/foo/bar/.+` and will go to service 3.
- `test.com/foo/bar/` matches `~* ^/foo/bar/` and will go to service 2.
- `test.com/foo/bar` matches `~* ^/foo/bar` and will go to service 1.
2018-10-01 17:54:11 +00:00
2018-10-12 01:09:01 +00:00
**IMPORTANT NOTES**:
2018-10-01 17:54:11 +00:00
2018-10-12 01:09:01 +00:00
- If the `use-regex` OR `rewrite-target` annotation is used on any Ingress for a given host, then the case insensitive regular expression [location modifier ](https://nginx.org/en/docs/http/ngx_http_core_module.html#location ) will be enforced on ALL paths for a given host regardless of what Ingress they are defined on.
2018-10-01 17:54:11 +00:00
## Warning
2018-10-12 01:09:01 +00:00
The following example describes a case that may inflict unwanted path matching behaviour.
This case is expected and a result of NGINX's a first match policy for paths that use the regular expression [location modifier ](https://nginx.org/en/docs/http/ngx_http_core_module.html#location ). For more information about how a path is chosen, please read the following article: ["Understanding Nginx Server and Location Block Selection Algorithms" ](https://www.digitalocean.com/community/tutorials/understanding-nginx-server-and-location-block-selection-algorithms ).
2018-10-01 17:54:11 +00:00
### Example
Let the following ingress be defined:
2018-10-12 01:09:01 +00:00
```yaml
2019-12-12 23:12:12 +00:00
apiVersion: networking.k8s.io/v1beta1
2018-10-01 17:54:11 +00:00
kind: Ingress
metadata:
2018-10-19 03:44:45 +00:00
name: test-ingress-3
2018-10-01 17:54:11 +00:00
annotations:
2018-10-19 03:44:45 +00:00
nginx.ingress.kubernetes.io/use-regex: "true"
2018-10-01 17:54:11 +00:00
spec:
rules:
2018-10-19 03:44:45 +00:00
- host: test.com
http:
paths:
- path: /foo/bar/bar
backend:
serviceName: test
servicePort: 80
- path: /foo/bar/[A-Z0-9]{3}
backend:
serviceName: test
servicePort: 80
2018-10-01 17:54:11 +00:00
```
2018-10-12 01:09:01 +00:00
The ingress controller would define the following location blocks (in this order) within the NGINX template for the `test.com` server:
2018-10-01 17:54:11 +00:00
2018-10-12 01:09:01 +00:00
```txt
2018-10-19 03:44:45 +00:00
location ~* "^/foo/bar/[A-Z0-9]{3}" {
2018-10-01 17:54:11 +00:00
...
}
2018-10-19 03:44:45 +00:00
location ~* "^/foo/bar/bar" {
2018-10-01 17:54:11 +00:00
...
}
```
A request to `test.com/foo/bar/bar` would match the `^/foo/[A-Z0-9]{3}` location block instead of the longest EXACT matching path.