From 9b9531d90dfd8a334958d23394afafd0185bfa21 Mon Sep 17 00:00:00 2001 From: Willy Tarreau Date: Sat, 28 Mar 2015 12:20:33 +0100 Subject: [PATCH 8/9] BUG/MINOR: compression: consider the expansion factor in init When checking if the buffer is large enough, we used to rely on a fixed size that was "apparently" enough. We need to consider the expansion factor of deflate-encoded streams instead, which is of 5 bytes per 32kB. The previous value was OK till 128kB buffers but became wrong past that. It's totally harmless since we always keep the reserve when compressiong, so there's 1kB or so available, which is enough for buffers as large as 6.5 MB, but better fix the check anyway. This fix could be backported into 1.5 since compression was added there. (cherry picked from commit 2aee2215c908c6997addcd1714b5b10f73c0703d) --- src/compression.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/src/compression.c b/src/compression.c index 3d6085e..d55f14e 100644 --- a/src/compression.c +++ b/src/compression.c @@ -130,9 +130,12 @@ int http_compression_buffer_init(struct session *s, struct buffer *in, struct bu { int left; - /* not enough space */ - if (in->size - buffer_len(in) < 40) - return -1; + /* output stream requires at least 10 bytes for the gzip header, plus + * at least 8 bytes for the gzip trailer (crc+len), plus a possible + * plus at most 5 bytes per 32kB block and 2 bytes to close the stream. + */ + if (in->size - buffer_len(in) < 20 + 5 * ((in->i + 32767) >> 15)) + return -1; /* We start by copying the current buffer's pending outgoing data into * a new temporary buffer that we initialize with a new empty chunk. -- 2.0.5