|
4 | 4 |
|
5 | 5 | :_mod-docs-content-type: PROCEDURE |
6 | 6 | [id="nw-http2-haproxy_{context}"] |
7 | | -= Enabling HTTP/2 Ingress connectivity |
| 7 | += Enabling and disabling HTTP/2 on Ingress Controllers |
8 | 8 |
|
9 | | -You can enable transparent end-to-end HTTP/2 connectivity in HAProxy. It allows application owners to make use of HTTP/2 protocol capabilities, including single connection, header compression, binary streams, and more. |
| 9 | +You can enable or disable transparent end-to-end HTTP/2 connectivity in HAProxy. This allows application owners to make use of HTTP/2 protocol capabilities, including single connection, header compression, binary streams, and more. |
10 | 10 |
|
11 | | -You can enable HTTP/2 connectivity for an individual Ingress Controller or for the entire cluster. |
| 11 | +You can enable or disable HTTP/2 connectivity for an individual Ingress Controller or for the entire cluster. |
12 | 12 |
|
13 | 13 | To enable the use of HTTP/2 for the connection from the client to HAProxy, a route must specify a custom certificate. A route that uses the default certificate cannot use HTTP/2. This restriction is necessary to avoid problems from connection coalescing, where the client re-uses a connection for different routes that use the same certificate. |
14 | 14 |
|
15 | | -The connection from HAProxy to the application pod can use HTTP/2 only for re-encrypt routes and not for edge-terminated or insecure routes. This restriction is because HAProxy uses Application-Level Protocol Negotiation (ALPN), which is a TLS extension, to negotiate the use of HTTP/2 with the back-end. The implication is that end-to-end HTTP/2 is possible with passthrough and re-encrypt and not with insecure or edge-terminated routes. |
| 15 | +The connection from HAProxy to the application pod can use HTTP/2 only for re-encrypt routes and not for edge-terminated or insecure routes. This restriction is because HAProxy uses Application-Level Protocol Negotiation (ALPN), which is a TLS extension, to negotiate the use of HTTP/2 with the back-end. The implication is that end-to-end HTTP/2 is possible with passthrough and re-encrypt and not with edge-terminated routes. |
16 | 16 |
|
17 | | -[IMPORTANT] |
| 17 | +[NOTE] |
18 | 18 | ==== |
19 | | -For non-passthrough routes, the Ingress Controller negotiates its connection to the application independently of the connection from the client. This means a client may connect to the Ingress Controller and negotiate HTTP/1.1, and the Ingress Controller may then connect to the application, negotiate HTTP/2, and forward the request from the client HTTP/1.1 connection using the HTTP/2 connection to the application. This poses a problem if the client subsequently tries to upgrade its connection from HTTP/1.1 to the WebSocket protocol, because the Ingress Controller cannot forward WebSocket to HTTP/2 and cannot upgrade its HTTP/2 connection to WebSocket. Consequently, if you have an application that is intended to accept WebSocket connections, it must not allow negotiating the HTTP/2 protocol or else clients will fail to upgrade to the WebSocket protocol. |
| 19 | +You can use HTTP/2 with an insecure route whether the Ingress Controller has HTTP/2 enabled or disabled. |
20 | 20 | ==== |
21 | 21 |
|
22 | | -.Procedure |
23 | | - |
24 | | -Enable HTTP/2 on a single Ingress Controller. |
25 | | - |
26 | | -* To enable HTTP/2 on an Ingress Controller, enter the `oc annotate` command: |
27 | | -+ |
28 | | -[source,terminal] |
29 | | ----- |
30 | | -$ oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=true |
31 | | ----- |
32 | | -+ |
33 | | -Replace `<ingresscontroller_name>` with the name of the Ingress Controller to annotate. |
34 | | -
|
35 | | -Enable HTTP/2 on the entire cluster. |
36 | | - |
37 | | -* To enable HTTP/2 for the entire cluster, enter the `oc annotate` command: |
38 | | -+ |
39 | | -[source,terminal] |
40 | | ----- |
41 | | -$ oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=true |
42 | | ----- |
43 | | -+ |
44 | | -[TIP] |
45 | | -==== |
46 | | -You can alternatively apply the following YAML to add the annotation: |
47 | | -[source,yaml] |
48 | | ----- |
49 | | -apiVersion: config.openshift.io/v1 |
50 | | -kind: Ingress |
51 | | -metadata: |
52 | | - name: cluster |
53 | | - annotations: |
54 | | - ingress.operator.openshift.io/default-enable-http2: "true" |
55 | | ----- |
| 22 | +[IMPORTANT] |
56 | 23 | ==== |
| 24 | +For non-passthrough routes, the Ingress Controller negotiates its connection to the application independently of the connection from the client. This means a client may connect to the Ingress Controller and negotiate HTTP/1.1, and the Ingress Controller might then connect to the application, negotiate HTTP/2, and forward the request from the client HTTP/1.1 connection using the HTTP/2 connection to the application. This poses a problem if the client subsequently tries to upgrade its connection from HTTP/1.1 to the WebSocket protocol, because the Ingress Controller cannot forward WebSocket to HTTP/2 and cannot upgrade its HTTP/2 connection to WebSocket. Consequently, if you have an application that is intended to accept WebSocket connections, it must not allow negotiating the HTTP/2 protocol or else clients will fail to upgrade to the WebSocket protocol. |
| 25 | +==== |
0 commit comments