You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 17, 2019. It is now read-only.
Copy file name to clipboardExpand all lines: hack/verify-flags/exceptions.txt
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,4 @@
1
-
ingress/controllers/nginx/configuration.md:Enables which HTTP codes should be passed for processing with the [error_page directive](http://nginx.org/en/docs/http/ngx_http_core_module.html#error_page)
1
+
ingress/controllers/nginx/configuration.md:**custom-http-errors:** Enables which HTTP codes should be passed for processing with the [error_page directive](http://nginx.org/en/docs/http/ngx_http_core_module.html#error_page)
2
2
ingress/controllers/nginx/configuration.md:Setting at least one code this also enables [proxy_intercept_errors](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_intercept_errors) (required to process error_page)
@@ -22,12 +22,12 @@ there are 3 ways to customize nginx
22
22
23
23
1. config map: create a stand alone config map, use this if you want a different global configuration
24
24
2. annoations: [annotate the ingress](#annotations), use this if you want a specific configuration for the site defined in the ingress rule
25
-
3. custom template: when do people want this?
25
+
3. custom template: when is required a specific setting like [open_file_cache](http://nginx.org/en/docs/http/ngx_http_core_module.html#open_file_cache), custom [log_format](http://nginx.org/en/docs/http/ngx_http_log_module.html#log_format), adjust [listen](http://nginx.org/en/docs/http/ngx_http_core_module.html#listen) options as `rcvbuf` or when is not possible to change an through the config map
26
26
27
27
28
28
#### Custom NGINX configuration
29
29
30
-
Using a config map it is possible to customize the defaults in nginx.
30
+
It's possible to customize the defaults in NGINX using a config map.
31
31
32
32
Please check the [custom configuration](examples/custom-configuration/README.md) example
33
33
@@ -47,7 +47,7 @@ The following annotaitons are supported:
47
47
|[ingress.kubernetes.io/ssl-redirect](#server-side-https-enforcement-through-redirect)|true or false|
@@ -62,7 +62,7 @@ Use the [custom-template](examples/custom-template/README.md) example as a guide
62
62
63
63
### Custom NGINX upstream checks
64
64
65
-
NGINX exposes some flags in the [upstream configuration](http://nginx.org/en/docs/http/ngx_http_upstream_module.html#upstream) that enables the configuration of each server in the upstream. The ingress controller allows custom `max_fails` and `fail_timeout` parameters in a global context using `upstream-max-fails` or `upstream-fail-timeout` in the NGINX config map or in a particular Ingress rule. By default this values are 0. This means NGINX will respect the `readinessProbe`, if is defined. If there is no probe, NGINX will not mark a server inside an upstream down.
65
+
NGINX exposes some flags in the [upstream configuration](http://nginx.org/en/docs/http/ngx_http_upstream_module.html#upstream) that enables the configuration of each server in the upstream. The ingress controller allows custom `max_fails` and `fail_timeout` parameters in a global context using `upstream-max-fails` or `upstream-fail-timeout` in the NGINX config map or in a particular Ingress rule. It defaults to 0. This means NGINX will respect the `readinessProbe`, if is defined. If there is no probe, NGINX will not mark a server inside an upstream down.
66
66
67
67
**With the default values NGINX will not health check your backends, and whenever the endpoints controller notices a readiness probe failure that pod's ip will be removed from the list of endpoints, causing nginx to also remove it from the upstreams.**
68
68
@@ -109,7 +109,8 @@ Please check the [auth](examples/custom-upstream-check/README.md) example
109
109
### Rewrite
110
110
111
111
In some scenarios the exposed URL in the backend service differs from the specified path in the Ingress rule. Without a rewrite any request will return 404.
112
-
To allow this is possible to use the annotation `ingress.kubernetes.io/rewrite-target` with the path expected in the service.
112
+
Set the annotation `ingress.kubernetes.io/rewrite-target` to the path expected by the service.
113
+
113
114
If the application contains relative links is possible to add an additional annotation `ingress.kubernetes.io/add-base-url` that will append a `base` tag in the header of the returned HTML from the backend.
114
115
115
116
@@ -125,17 +126,17 @@ The annotations `ingress.kubernetes.io/limit-connections` and `ingress.kubernete
125
126
`ingress.kubernetes.io/limit-rps`: number of allowed connections per second from a single IP address
126
127
127
128
128
-
Is possible to specify both annotation in the same Ingress rule. In this case the order of the limit is `limit-connections` and then `limit-rps`
129
+
Is possible to specify both annotation in the same Ingress rule. If you specify both annotations in a single Ingress rule, limit-rps takes precedence
129
130
130
131
131
132
### Secure upstreams
132
133
133
-
By default NGINX uses `http` to reach the services. Adding the annotation `ingress.kubernetes.io/secure-upstream: "true"` in the ingress rule changes the protocol to `https`.
134
+
By default NGINX uses `http` to reach the services. Adding the annotation `ingress.kubernetes.io/secure-backends: "true"` in the ingress rule changes the protocol to `https`.
134
135
135
136
136
137
### Whitelist source range
137
138
138
-
Using the annotation `ingress.kubernetes.io/whitelist-source-range`is possible to specify one or ranges of client IP addresses from which is possible to access the `Path` in the Ingress rule, e.g.`10.0.0.0/24,172.10.0.1`
139
+
You can specify the allowed client ip source ranges through the `ingress.kubernetes.io/whitelist-source-range`annotation, eg; `10.0.0.0/24,172.10.0.1`
139
140
For a global restriction (any URL) is possible to use `whitelist-source-range` in the NGINX config map
140
141
141
142
*Note:* adding an annotation overrides any global restriction
@@ -169,12 +170,8 @@ The previous behavior can be restored using the value "true"
169
170
170
171
171
172
**hsts:** Enables or disables the header HSTS in servers running SSL.
172
-
HTTP Strict Transport Security (often abbreviated as HSTS) is a security feature (HTTP header) that tell browsers that it should only be communicated with using HTTPS, instead of using HTTP.
173
+
HTTP Strict Transport Security (often abbreviated as HSTS) is a security feature (HTTP header) that tell browsers that it should only be communicated with using HTTPS, instead of using HTTP. It provides protection against protocol downgrade attacks and cookie theft.
0 commit comments