Description of problem: Unable to access kibana URL after enabling HTTP2 on haproxy router. Which was working fine with lower versions of OCP ( <= OCP 3.11.316) When we change the haproxy router image to ose-haproxy-router:v3.11.306-10. Kibana URL is working as expected. Version-Release number of selected component (if applicable): How reproducible: We can reproduce on any OCP 3.11 version greater than OCP 3.11.317 Steps to Reproduce: 1. Setup the cluster with logging stack 2. Enable HTTP2 with below command oc set env dc/router ROUTER_ENABLE_HTTP2=true 3. Access kibana URL and you would end with and error. Kibana did not load properly Actual results: Kibana application page is not loading properly Expected results: Working kibana web console is expected Additional info:
This looks to be an issue in haproxy-1.8.26; https://github.com/haproxy/haproxy/issues/884#issuecomment-748379574 We should bump to 1.8.28 which appears to be the latest release.
*** Bug 1921122 has been marked as a duplicate of this bug. ***
Hi, I'd like to follow this issue. I'm tracking in my opened case https://access.redhat.com/support/cases/#/case/02829567. Thank's!
Hi Candace, I have attached files which you have requested. Thanks, Vijay
I am bumping the HAProxy version to 1.8.28 as mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1918392#c4
The HAProxy 1.8.28 RPM has passed all CI testing and was copied to the 3.11 RPM mirror. It will be available in the next OCP 3.11 version. QE - please verify in the next 3.11 version.
Verified with v3.11.394 and passed. kibana web console is still working well after enable HTTP2. # oc version oc v3.11.394 kubernetes v1.11.0+d4cacc0 features: Basic-Auth GSSAPI Kerberos SPNEGO Server https://hongli-311master-etcd-1:8443 openshift v3.11.394 kubernetes v1.11.0+d4cacc0 sh-4.2$ haproxy -v HA-Proxy version 1.8.28-ef7a974 2021/01/13 Copyright 2000-2021 Willy Tarreau <willy> sh-4.2$ sh-4.2$ rpm -qa | grep haproxy haproxy18-1.8.28-1.el7.x86_64
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Important: OpenShift Container Platform 3.11.394 bug fix and security update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2021:0637
The change that we wanted to pickup from upstream was: commit 179d316c9fcb0651be5b4c2493b8df3a635fa2ff Author: Christopher Faulet <cfaulet> Date: Wed Aug 5 14:37:13 2020 +0200 BUG/MEDIUM: mux-h2: Don't fail if nothing is parsed for a legacy chunk response The parsing of incomplete chunk formatting in legacy HTTP mode was fixed by the commit 6ad7cd981 ("BUG/MEDIUM: mux-h2: Emit an error if the response chunk formatting is incomplete"). But a bug was introduced. When nothing is parsed, an error is also returned. It may happens if the parsing is stopped just after a chunk CRLF. When we try to parse the following chunk size, if there is no more data to parse, an protocol error is returned. It is obviously wrong. The patch was directly introduced on 2.0, there is no upstream commit ID for this patch. This patch is related to issue #798 and reported in comment in issue #768. It must be backported to 1.8. (cherry picked from commit 307f31ec34926965ef5c8f4f5b1d7840538f8246) Signed-off-by: Christopher Faulet <cfaulet>