From 5121e5d7508e3b403a844b92d31bcac7efaf6dd7 Mon Sep 17 00:00:00 2001 From: Willy Tarreau Date: Mon, 6 May 2019 15:13:41 +0200 Subject: [PATCH] BUG/MINOR: mux-h2: rely on trailers output not input to turn them to empty data When sending trailers, we may face an empty HTX trailers block or even have to discard some of the headers there and be left with nothing to send. RFC7540 forbids sending of empty HEADERS frames, so in this case we turn to DATA frames (which is possible since after other DATA). The code used to only check the input frame's contents to decide whether or not to switch to a DATA frame, it didn't consider the possibility that the frame only used to contain headers discarded later, thus it could still emit an empty HEADERS frame in such a case. This patch makes sure that the output frame size is checked instead to take the decision. This patch must be backported to 1.9. In practice this situation is never encountered since the discarded headers have really nothing to do in a trailers block. --- src/mux_h2.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/src/mux_h2.c b/src/mux_h2.c index 55d69a28e..baf84d4ef 100644 --- a/src/mux_h2.c +++ b/src/mux_h2.c @@ -5096,11 +5096,12 @@ static size_t h2s_htx_make_trailers(struct h2s *h2s, struct htx *htx) } } - if (!hdr) { - /* here we have a problem, we've received an empty trailers - * block followed by an EOM. Because of this we can't send a - * HEADERS frame, so we have to cheat and instead send an empty - * DATA frame conveying the ES flag. + if (outbuf.data == 9) { + /* here we have a problem, we have nothing to emit (either we + * received an empty trailers block followed or we removed its + * contents above). Because of this we can't send a HEADERS + * frame, so we have to cheat and instead send an empty DATA + * frame conveying the ES flag. */ outbuf.area[3] = H2_FT_DATA; outbuf.area[4] = H2_F_DATA_END_STREAM;