Fix documentation links [skip ci]

docs/examples/index.md

@@ -15,7 +15,6 @@ Customization | [Custom configuration](customization/custom-configuration/README
 Customization | [Custom DH parameters for perfect forward secrecy](customization/ssl-dh-param/README.md) | TODO | TODO
 Customization | [Custom errors](customization/custom-errors/README.md) | serve custom error pages from the default backend | Intermediate
 Customization | [Custom headers](customization/custom-headers/README.md) | set custom headers before sending traffic to backends  | Advanced
-Customization | [Custom upstream check](customization/custom-upstream-check/README.md) | TODO | TODO
 Customization | [External authentication with response header propagation](customization/external-auth-headers/README.md) | TODO | TODO
 Customization | [Sysctl tuning](customization/sysctl/README.md) | TODO | TODO
 Features | [Rewrite](rewrite/README.md) | TODO | TODO

docs/user-guide/ingress-path-matching.md

@@ -4,10 +4,9 @@
 
 The ingress controller supports **case insensitive** regular expressions in the `spec.rules.http.paths.path` field.
 
+See the [description](./nginx-configuration/annotations.md#use-regex) of the `use-regex` annotation for more details.
 
-See the [description](./nginx-configuration/annotations.md#use-regex) of the `use-regex` annotation for more details. 
-
-```
+```yaml
 apiVersion: extensions/v1beta1
 kind: Ingress
 metadata:
@@ -17,53 +16,53 @@ metadata:
 spec:
   host: test.com
   rules:
-  - http:
-      paths:
-      - path: /foo/.*
-        backend:
-          serviceName: test
-          servicePort: 80
+    - http:
+        paths:
+          - path: /foo/.*
+            backend:
+              serviceName: test
+              servicePort: 80
 ```
 
 The preceding ingress definition would translate to the following location block within the NGINX configuration for the `test.com` server:
 
-```
+```txt
 location ~* ^/foo/.* {
   ...
 }
 ```
 
 ## Path Priority
 
-In NGINX, regular expressions follow a **first match** policy. In order to enable more acurate path matching, ingress-nginx first orders the paths by descending length before writing them to the NGINX template as location blocks. 
+In NGINX, regular expressions follow a **first match** policy. In order to enable more acurate path matching, ingress-nginx first orders the paths by descending length before writing them to the NGINX template as location blocks.
 
-__Please read the [warning](#warning) before using regular expressions in your ingress definitions.__
+**Please read the [warning](#warning) before using regular expressions in your ingress definitions.**
 
 ### Example
 
 Let the following two ingress definitions be created:
 
-```
+```yaml
 apiVersion: extensions/v1beta1
 kind: Ingress
 metadata:
   name: test-ingress-1
 spec:
   host: test.com
   rules:
-  - http:
-      paths:
-      - path: /foo/bar
-        backend:
-          serviceName: test
-          servicePort: 80
-      - path: /foo/bar/
-        backend:
-          serviceName: test
-          servicePort: 80
+    - http:
+        paths:
+          - path: /foo/bar
+            backend:
+              serviceName: test
+              servicePort: 80
+          - path: /foo/bar/
+            backend:
+              serviceName: test
+              servicePort: 80
 ```
 
-```
+```yaml
 apiVersion: extensions/v1beta1
 kind: Ingress
 metadata:
@@ -73,19 +72,17 @@ metadata:
 spec:
   host: test.com
   rules:
-  - http:
-      paths:
-      - path: /foo/bar/.+
-        backend:
-          serviceName: test
-          servicePort: 80
+    - http:
+        paths:
+          - path: /foo/bar/.+
+            backend:
+              serviceName: test
+              servicePort: 80
 ```
 
+The ingress controller would define the following location blocks, in order of descending length, within the NGINX template for the `test.com` server:
 
-
-The ingress controller would define the following location blocks, in order of descending length, within the NGINX template for the `test.com` server: 
-
-```
+```txt
 location ~* ^/foo/bar/.+\/?(?<baseuri>.*) {
   ...
 }
@@ -98,26 +95,29 @@ location ~* ^/foo/bar {
   ...
 }
 ```
+
 The following request URI's would match the corresponding location blocks:
+
 - `test.com/foo/bar/1` matches `~* ^/foo/bar/.+\/?(?<baseuri>.*)`
 - `test.com/foo/bar/` matches `~* ^/foo/bar/`
 - `test.com/foo/bar` matches `~* ^/foo/bar`
 
-__IMPORTANT NOTES__: 
-- paths created under the `rewrite-ingress` are sorted before `\/?(?<baseuri>.*)` is appended. For example if the path defined within `test-ingress-2` was `/foo/.+` then the location block for `^/foo/.+\/?(?<baseuri>.*)` would be the LAST block listed.
-- 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.  
+**IMPORTANT NOTES**:
 
+- paths created under the `rewrite-ingress` are sorted before `\/?(?<baseuri>.*)` is appended. For example if the path defined within `test-ingress-2` was `/foo/.+` then the location block for `^/foo/.+\/?(?<baseuri>.*)` would be the LAST block listed.
+- 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.
 
 ## Warning
-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). 
+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).
 
 ### Example
 
 Let the following ingress be defined:
 
-```
+```yaml
 apiVersion: extensions/v1beta1
 kind: Ingress
 metadata:
@@ -127,21 +127,21 @@ metadata:
 spec:
   host: test.com
   rules:
-  - http:
-      paths:
-      - path: /foo/bar/bar
-        backend:
-          serviceName: test
-          servicePort: 80
-      - path: /foo/bar/[A-Z0-9]{3}
-        backend:
-          serviceName: test
-          servicePort: 80
+    - http:
+        paths:
+          - path: /foo/bar/bar
+            backend:
+              serviceName: test
+              servicePort: 80
+          - path: /foo/bar/[A-Z0-9]{3}
+            backend:
+              serviceName: test
+              servicePort: 80
 ```
 
-The ingress controller would define the following location blocks (in this order) within the NGINX template for the `test.com` server: 
+The ingress controller would define the following location blocks (in this order) within the NGINX template for the `test.com` server:
 
-```
+```txt
 location ~* ^/foo/bar/[A-Z0-9]{3} {
   ...
 }
@@ -152,4 +152,3 @@ location ~* ^/foo/bar/bar {
 ```
 
 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.
-

mkdocs.yml

@@ -4,8 +4,7 @@ repo_name: "kubernetes/ingress-nginx"
 repo_url: "https://github.com/kubernetes/ingress-nginx"
 markdown_extensions:
   - admonition
-  - codehilite:
-      linenums: true
+  - codehilite
   - pymdownx.inlinehilite
   - pymdownx.tasklist:
       custom_checkbox: true
@@ -51,7 +50,7 @@ nav:
       - Command line arguments: "user-guide/cli-arguments.md"
       - Custom errors: "user-guide/custom-errors.md"
       - Default backend: "user-guide/default-backend.md"
-      - Exposing TCP and UDP services: "user-guide/exposing-tcp-udp-services.md"
+      - Regular expressions in paths: user-guide/ingress-path-matching.md
       - External Articles: "user-guide/external-articles.md"
       - Miscellaneous: "user-guide/miscellaneous.md"
       - Prometheus and Grafana installation: "user-guide/monitoring.md"
@@ -74,7 +73,6 @@ nav:
           - Custom Configuration: "examples/customization/custom-configuration/README.md"
           - Custom Errors: "examples/customization/custom-errors/README.md"
           - Custom Headers: "examples/customization/custom-headers/README.md"
-          - Custom Upstream server checks: "examples/customization/custom-upstream-check/README.md"
           - External authentication: "examples/customization/external-auth-headers/README.md"
           - Custom DH parameters for perfect forward secrecy: "examples/customization/ssl-dh-param/README.md"
           - Sysctl tuning: "examples/customization/sysctl/README.md"