Description of problem: BZ 1825354 surfaced because http/2 protocol negotiation was added to cluster ingress in 4.4. In general, we cannot support HTTP/2 ALPN on routes that use the default certificate without risk of connection re-use/coalescing [1] causing problems identified in the BZ. This would have been caught before [2] merged if an e2e test existed that has a client auth against console with oauth templates. This BZ is a request to add such test to avoid similar issues in the future. Version-Release number of selected component (if applicable): 4.5 How reproducible: always Steps to Reproduce: See BZ 1825354 for details Actual results: Console returns a 503 error page instead of the login page. Expected results: The console login page. Additional info: See [3] for the ingress controller connection logs to see the difference in behavior between successful (HTTP/1.1) and failed (HTTP/2) connections. [1] https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/ [2] https://github.com/openshift/router/pull/75/files [3] https://gist.github.com/danehans/9bd5109d13d3c55f4c5a4ce76ecdbd6a
Can you clarify how templates are involved? This looks to be a case of router trying to pass http/2 traffic to a backend that does not support http/2. The oauth-server does not server http/2 at all, so I don't understand why http/2 traffic would get routed to it.
From the xref's BZ: In OpenShift 4.4, we enabled HTTP/2 on the frontend for the ingress controller; that is, we allow clients to ask the ingress controller to use HTTP/2, using ALPN. Because the console and oauth-server are both behind the ingress controller's balancer and are using the same serving certificate (namely the ingress controller's default certificate), a browser might perform connection coalescing[1], meaning the browser re-uses the connection that it used to connect to the console route to connect to the oauth route. Because we enabled HTTP/2 on the frontend, this means the browser may connect to the console route using HTTP/2 and then re-use the HTTP/2 connection to try to connect to the oauth route, which fails. In general, we cannot support HTTP/2 ALPN on routes that use the default certificate without risk of connection re-use/coalescing causing problems of this nature. To unblock this issue, we can disable HTTP/2 on the frontend. Later on, in order to support HTTP/2, we will need a solution that enables HTTP/2 only for routes that have custom certificates (which should prevent browsers from coalescing connections). 1. https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/
@Daneyon reading #2 in the context of David's #1, do you agree that we can close this BZ? At best, the issue you see is a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1727834. Closing. Please reopen if you disagree. *** This bug has been marked as a duplicate of bug 1727834 ***