Hi Willy,
Le 17/12/2018 à 14:13, Arnall a écrit :
Le 16/12/2018 à 23:05, Willy Tarreau a écrit :
I expected to release this week-end after running it on the haproxy.org
servers, but some annoying issues faced in production took some time to
get fixed and delayed the release.
Things have been quiet now, with 18 hours running without a glitch in
legacy mode (without HTX) and now 13 hours an counting with HTX enabled,
so things are getting much better.
Hello Willy,
don't know if it's related but haproxy.org answers with 400 status right
now !
(Windows 10 Chrome/Firefox)
I think I have met the exact same issue when I enabled HTX on a small
test config.
There's a bug with cookies and HTX.
When haproxy sends the headers to the backend server, it leaks 6 more
bytes at the end of the cookie value, which is the length of the name
"cookie".
This is due to this part of code :
http://git.haproxy.org/?p=haproxy.git;a=blob;f=src/h2.c;h=1b784fd4aba2dbad91db156612243e93aa34e5f3;hb=HEAD#l533
http://git.haproxy.org/?p=haproxy.git;a=blob;f=src/h2.c;h=1b784fd4aba2dbad91db156612243e93aa34e5f3;hb=HEAD#l557
htx_set_blk_value_len(blk, bs + 2 + vl);
Here, we set the new block value length, but bs is not the value length,
it the whole block size :
http://git.haproxy.org/?p=haproxy.git;a=blob;f=src/h2.c;h=1b784fd4aba2dbad91db156612243e93aa34e5f3;hb=HEAD#l542
542 blk = htx_add_header(htx, ist("cookie"), list[ck].v);
543 if (!blk)
544 goto fail;
545
546 fs = htx_free_data_space(htx);
547 bs = htx_get_blksz(blk);
I'm not sure how to fix this properly. I'd say we can store list[ck].v
in a "bvl" variable, update this variable while looping on the cookie
values, then set the new block value length according to this result.
Or is there a function to explicitely update the block size (kind of
htx_set_blksz) ?
I prefer to report the bug quickly so you can fix it today. Or I can
work on a patch, but this will not be before the end of the day ;-)
--
Cyril Bonté
