mirror of
https://git.haproxy.org/git/haproxy.git/
synced 2026-05-15 10:16:10 +02:00
00941af7b7
As reported by Huangbin Zhan (@zhanhb) in github issue #3355, latest commit 96f7ff4fdd ("MINOR: mux-h2: add a new message flag to indicate ext connect support") was not correct and can break RFC8441-compliant clients, as it did for them with a variant of Chrome 142. The problem is that while RFC9113 says that new pseudo-headers are only permitted with *negotiated* extensions, and RFC8441 doesn't indicate whether or not SETTINGS_ENABLE_CONNECT_PROTOCOL is needed from clients, it only says that clients know that servers support the extension when seeing it in their settings and can use it, which seems to imply that they don't need to send it to indicate their willingness to use it. This also means that the server cannot know if a client is expected to use it or not by default. It only know that a client is not allowed to use it if the server didn't emit support mentioning it, which haproxy can do using h2-workaround-bogus-websocket-clients. Thus the fix proposed by @zhanhb is right, when presetting the flag for the parser to indicate whether or not we're willing to accept RFC8441's :protocol pseudo-header, we should: - consider the received setting on the backend side (though the pseudo-header is neither used nor supported there, but at least we pass the info regarding the support of the extension) - consider the configuration for the frontend (since it's the only place where we can decide on support or not) This patch does just that and reverts the accompanying changes to the regtests that made them want to see the client's setting. It must be backported to 2.6. In the mean time, placing this option in the global section will force the clients to downgrade to h1: h2-workaround-bogus-websocket-clients Many thanks again to @zhanbb this feedback and proposing a tested fix.