Le 29/12/2018 à 01:29, PiBa-NL a écrit :
Hi List,

When using compression with htx, and a slightly delayed body content it will prefix some rubbish and corrupt the gzip header..

Below output i get with attached test.. Removing http-use-htx 'fixes' the test.

This happens with both 1.9.0 and todays commit a2dbeb2, not sure if this ever worked before..

**** c1    0.1 len|1A\r
**** c1    0.1 chunk|\222\7\0\0\0\377\377\213\10\0\0\0\0\0\4\3JLJN\1\0\0\0\377\377
**** c1    0.1 len|0\r
**** c1    0.1 bodylen = 26
**   c1    0.1 === expect resp.status == 200
**** c1    0.1 EXPECT resp.status (200) == "200" match
**   c1    0.1 === expect resp.http.content-encoding == "gzip"
**** c1    0.1 EXPECT resp.http.content-encoding (gzip) == "gzip" match
**   c1    0.1 === gunzip
---- c1    0.1 Gunzip error: Body lacks gzip magics

Can someone take a look? Thanks in advance.


Hi Pieter,

In fact, It is not a bug related to the compression. But a pure HTX one, about the defragmentation when we need space to store data. Here is a patch. It fixes the problem for me.

Willy, if it is ok for you, I can merge it in upstream and backport it in 1.9.

--
Christopher Faulet
>From a6e9d6be951b8724921d1582a2cddea81b5b6a6a Mon Sep 17 00:00:00 2001
From: Christopher Faulet <cfau...@haproxy.com>
Date: Wed, 2 Jan 2019 11:23:44 +0100
Subject: [PATCH] BUG/MAJOR: htx: Return the good block address after a defrag

When an HTX structure is defragmented, it is possible to retrieve the new block
corresponding to an old one. This is useful to do a defrag during a loop on
blocks, to be sure to continue looping on the good block. But, instead of
returning the address of the new block in the HTX structure, the one in the
temporary structure used to do the defrag was returned, leading to unexpected
behaviours.

This patch must be backported to 1.9.
---
 src/htx.c | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/src/htx.c b/src/htx.c
index bda293b43..83243e060 100644
--- a/src/htx.c
+++ b/src/htx.c
@@ -26,13 +26,15 @@ struct htx_blk *htx_defrag(struct htx *htx, struct htx_blk *blk)
 	struct buffer *chunk = get_trash_chunk();
 	struct htx *tmp = htxbuf(chunk);
 	struct htx_blk *newblk, *oldblk;
-	uint32_t new, old;
+	uint32_t new, old, blkpos;
 	uint32_t addr, blksz;
 	int32_t sl_off = -1;
 
 	if (!htx->used)
 		return NULL;
 
+	blkpos = -1;
+
 	new  = 0;
 	addr = 0;
 	tmp->size = htx->size;
@@ -54,13 +56,14 @@ struct htx_blk *htx_defrag(struct htx *htx, struct htx_blk *blk)
 		if (htx->sl_off == oldblk->addr)
 			sl_off = addr;
 
+		/* if <blk> is defined, set its new position */
+		if (blk != NULL && blk == oldblk)
+			blkpos = new;
+
 		memcpy((void *)tmp->blocks + addr, htx_get_blk_ptr(htx, oldblk), blksz);
 		new++;
 		addr += blksz;
 
-		/* if <blk> is defined, set its new location */
-		if (blk != NULL && blk == oldblk)
-			blk = newblk;
 	} while (new < htx->used);
 
 	htx->sl_off = sl_off;
@@ -68,7 +71,7 @@ struct htx_blk *htx_defrag(struct htx *htx, struct htx_blk *blk)
 	htx->front = htx->tail = new - 1;
 	memcpy((void *)htx->blocks, (void *)tmp->blocks, htx->size);
 
-	return blk;
+	return ((blkpos == -1) ? NULL : htx_get_blk(htx, blkpos));
 }
 
 /* Reserves a new block in the HTTP message <htx> with a content of <blksz>
-- 
2.19.2

Reply via email to