BUG/MEDIUM: mux-h2: Don't handle pending read0 too early on streams
This patch is similar to the previous one on the fcgi. Same is true for the
H2. But the bug is far harder to trigger because of the protocol cinematic. But
it may explain strange aborts in some edge cases.
A read0 received on the connection must not be handled too early by H2 streams.
If the demux buffer is not empty, the pending read0 must not be considered. The
H2 streams must not be passed in half-closed remote state in
h2s_wake_one_stream() and the CS_FL_EOS flag must not be set on the associated
conn-stream in h2_rcv_buf(). To sum up, it means, if there are still data
pending in the demux buffer, no abort must be reported to the streams.
To fix the issue, a dedicated function has been added, responsible for detecting
pending read0 for a H2 connection. A read0 is reported only if the demux buffer
is empty. This function is used instead of conn_xprt_read0_pending() at some
places.
Note that the HREM stream state should not be used to report aborts. It is
performed on h2s_wake_one_stream() function and it is a legacy of the very first
versions of the mux-h2.
This patch should be backported as far as 2.0. In the 1.8, the code is too
different to apply it like that. But it is probably useless because the mux-h2
can only be installed on the client side.
(cherry picked from commit aade4edc1a8d148447953e279c6a83bf3dea6661)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 36840d8ca8e298b4da4bd24d0f6128b46e0757e3)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit e77e79d29220759de8da22ed518e12cecefda520)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
1 file changed