From 7571015939eb0ab560df0fefc434e273ec9d93ff Mon Sep 17 00:00:00 2001 From: Willy Tarreau Date: Tue, 11 Dec 2018 06:46:03 +0100 Subject: [PATCH] BUG/MINOR: hpack: fix off-by-one in header name encoding length calculation In hpack_encode_header() there is a length check to verify that a literal header name fits in the buffer, but there it an off-by-one in this length check, which forgets the byte required to mark the encoding type (literal without indexing). It should be harmless though as it cannot be triggered since response headers passing through haproxy are limited by the reserve, which is not the case of the output buffer. This fix should be backported to 1.8. --- src/hpack-enc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/hpack-enc.c b/src/hpack-enc.c index c4c8ea240..836584ab4 100644 --- a/src/hpack-enc.c +++ b/src/hpack-enc.c @@ -109,7 +109,7 @@ int hpack_encode_header(struct buffer *out, const struct ist n, out->area[len++] = 0x58; // literal with indexing -- name="cache-control" (idx 24) else if (isteq(n, ist("content-length"))) out->area[len++] = 0x5c; // literal with indexing -- name="content-length" (idx 28) - else if (len_to_bytes(n.len) && len + len_to_bytes(n.len) + n.len <= size) { + else if (len_to_bytes(n.len) && len + 1 + len_to_bytes(n.len) + n.len <= size) { out->area[len++] = 0x00; /* literal without indexing -- new name */ len = hpack_encode_len(out->area, len, n.len);