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
Implement request redirect filter in HTTPRoute rule (#218)
This commit implements the request redirect filter as part of the routing
rule in the HTTPRoute.
A common use-case for a request redirect is redirecting HTTP requests
to HTTPS. The commit updates the HTTPS termination example to include
HTTPS redirect configuration.
Notes:
- The experimental 'path' field of 'requestRedirect' is out of scope.
- The validation of the fields of `requestRedirect` is not implemented.
It is left to be done in a separate component responsible for validation
with FIXMEs added to the relevant code locations.
- If multiple redirect filters are configured, NGINX Kubernetes Gateway
will choose the first one and ignore the rest.
- NGINX will always redirect a request even if the request has already
been redirected. Thus, any backendRefs defined in the routing rule will
be ignored. However, that "always redirect" behavior is not specified
by the Gateway API. As a result, we might need to change our
implementation if different behavior becomes specified by the Gateway API
in the future.
Copy file name to clipboardExpand all lines: docs/gateway-api-compatibility.md.md
+4-1
Original file line number
Diff line number
Diff line change
@@ -87,7 +87,10 @@ Fields:
87
87
* `headers` - partially supported. Only `Exact` type.
88
88
* `queryParams` - partially supported. Only `Exact` type.
89
89
* `method` - supported.
90
-
* `filters` - not supported.
90
+
* `filters`
91
+
* `type` - supported.
92
+
* `requestRedirect` - supported except for the experimental `path` field. If multiple filters with `requestRedirect` are configured, NGINX Kubernetes Gateway will choose the first one and ignore the rest.
93
+
* `requestHeaderModifier`, `requestMirror`, `urlRewrite`, `extensionRef` - not supported.
91
94
* `backendRefs` - partially supported. Only a single backend ref without support for `weight`. Backend ref `filters` are not supported. NGINX Kubernetes Gateway will use the IP of the Service as a backend, not the IPs of the corresponding Pods. Watching for Service updates is not supported.
Copy file name to clipboardExpand all lines: examples/https-termination/README.md
+43-8
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
# HTTPS Termination Example
2
2
3
-
In this example we expand on the simple [cafe-example](../cafe-example) by adding HTTPS termination to our routes.
3
+
In this example, we expand on the simple [cafe-example](../cafe-example) by adding HTTPS termination to our routes and an HTTPS redirect from port 80 to 443.
4
4
5
5
## Running the Example
6
6
@@ -14,10 +14,11 @@ In this example we expand on the simple [cafe-example](../cafe-example) by addin
14
14
GW_IP=XXX.YYY.ZZZ.III
15
15
```
16
16
17
-
1. Save the HTTPS port of NGINX Kubernetes Gateway:
17
+
1. Save the ports of NGINX Kubernetes Gateway:
18
18
19
19
```
20
-
GW_HTTPS_PORT=port
20
+
GW_HTTP_PORT=<http port number>
21
+
GW_HTTPS_PORT=<https port number>
21
22
```
22
23
23
24
## 2. Deploy the Cafe Application
@@ -52,26 +53,60 @@ In this example we expand on the simple [cafe-example](../cafe-example) by addin
52
53
kubectl apply -f gateway.yaml
53
54
```
54
55
55
-
This [gateway](./gateway.yaml) configures an `https` listener is to terminate TLS connections using the `cafe-secret` we created in the step 1.
56
+
This [Gateway](./gateway.yaml) configures:
57
+
*`http` listener for HTTP traffic
58
+
*`https` listener for HTTPS traffic. It terminates TLS connections using the `cafe-secret` we created in step 1.
56
59
57
60
1. Create the `HTTPRoute` resources:
58
61
```
59
62
kubectl apply -f cafe-routes.yaml
60
63
```
61
64
62
-
To configure HTTPS termination for our cafe application, we will bind the `https` listener to our `HTTPRoutes` in [cafe-routes.yaml](./cafe-routes.yaml) using the [`parentReference`](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.ParentReference) field:
65
+
To configure HTTPS termination for our cafe application, we will bind our `coffee` and `tea` HTTPRoutes to the `https` listener in [cafe-routes.yaml](./cafe-routes.yaml) using the [`parentReference`](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.ParentReference) field:
63
66
64
67
```yaml
65
68
parentRefs:
66
69
- name: gateway
67
-
namespace: default
68
70
sectionName: https
69
71
```
70
72
73
+
To configure an HTTPS redirect from port 80 to 443, we will bind the special `cafe-tls-redirect` HTTPRoute with a [`HTTPRequestRedirectFilter`](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.HTTPRequestRedirectFilter) to the `http` listener:
74
+
75
+
```yaml
76
+
parentRefs:
77
+
- name: gateway
78
+
sectionName: http
79
+
```
80
+
71
81
## 4. Test the Application
72
82
73
-
To access the application, we will use `curl` to send requests to the `coffee` and `tea` Services.
74
-
Since our certificate is self-signed, we'll use curl's `--insecure` option to turn off certificate verification.
83
+
To access the application, we will use `curl` to send requests to the `coffee` and `tea` Services. First, we will access the application over HTTP to test that the HTTPS redirect works. Then we will use HTTPS.
84
+
85
+
### 4.1 Test HTTPS Redirect
86
+
87
+
To test that NGINX sends an HTTPS redirect, we will send requests to the `coffee` and `tea` Services on HTTP port. We will use curl's `--include` option to print the response headers (we are interested in the `Location` header).
Now we will access the application over HTTPS. Since our certificate is self-signed, we will use curl's `--insecure` option to turn off certificate verification.
0 commit comments