|
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