]> git.ipfire.org Git - thirdparty/haproxy.git/commit
BUG/MEDIUM: h2: Only report early HTX EOM for tunneled streams
authorChristopher Faulet <cfaulet@haproxy.com>
Thu, 1 Aug 2024 14:01:50 +0000 (16:01 +0200)
committerChristopher Faulet <cfaulet@haproxy.com>
Fri, 2 Aug 2024 06:42:28 +0000 (08:42 +0200)
commit6743e128f34fba297f2cac836a4f11b84acd503a
treeb17dd067c31fe2bcfad944b12fe930f7cd24595b
parent0ba6202796fe24099aeff89a5a4b83af99fc027b
BUG/MEDIUM: h2: Only report early HTX EOM for tunneled streams

For regular H2 messages, the HTX EOM flag is synonymous the end of input. So
SE_FL_EOI flag must also be set on the stream-endpoint descriptor. However,
there is an exception. For tunneled streams, the end of message is reported
on the HTX message just after the headers. But in that case, no end of input
is reported on the SE.

But here, there is a bug. The "early" EOM is also report on the HTX messages
when there is no payload (for instance a content-length set to 0). If there
is no ES flag on the H2 HEADERS frame, it is an unexpected case. Because for
the applicative stream and most probably for the opposite endpoint, the
message is considered as finihsed. It is switched in its DONE state (or the
equivalent on the endpoint). But, if an extra H2 frame with the ES flag is
received, a TRAILERS frame or an emtpy DATA frame, an extra EOT HTX block is
pushed to carry the HTX EOM flag. So an extra HTX block is emitted for a
regular HTX message. It is totally invalid, it must never happen.

Because it is an undefined behavior, it is difficult to predict the result.
But it definitly prevent the applicative stream to properly handle aborts
and errors because data remain blocked in the channel buffer. Indeed, the
end of the message was seen, so no more data are forwarded.

It seems to be an issue for 2.8 and upper. Harder to evaluate for older
versions.

This patch must be backported as far as 2.4.
src/h2.c