BUG/MEDIUM: stats-html: Never dump more data than expected during 0-copy FF

During the zero-copy data forwarding, the caller specify the maximum amount
of data the producer may push. However, the HTML stats applet does not use
it and can fill all the free space in the buffer.  It is especially an issue
when the consumer is limited by a flow control, like the H2. Because we may
emit too large DATA frame in this case. It is especially visible with big
buffer (for instance 32k).

In the early age or zero-copy data forwarding, the caller was responsible to
pass a properly resized buffer. And during the different refactoring steps,
this has changed but the HTML stats applet was not updated accordingly.

To fix the bug, the buffer used to dump the HTML page is resized to be sure
not too much data are dumped.

This patch should solve the issue #2757. It must be backported to 3.0.
This commit is contained in:
Christopher Faulet 2024-10-22 07:47:41 +02:00
parent f2c415cec1
commit 529e4f36a3
1 changed files with 6 additions and 5 deletions

View File

@ -2080,16 +2080,17 @@ static size_t http_stats_fastfwd(struct appctx *appctx, struct buffer *buf,
size_t count, unsigned int flags)
{
struct stconn *sc = appctx_sc(appctx);
size_t ret = 0;
struct buffer outbuf;
size_t ret;
ret = b_data(buf);
if (stats_dump_stat_to_buffer(sc, buf, NULL)) {
outbuf = b_make(b_tail(buf), MIN(count, b_contig_space(buf)), 0, 0);
if (stats_dump_stat_to_buffer(sc, &outbuf, NULL)) {
se_fl_clr(appctx->sedesc, SE_FL_MAY_FASTFWD_PROD);
applet_fl_clr(appctx, APPCTX_FL_FASTFWD);
appctx->st0 = STAT_HTTP_DONE;
}
ret = b_data(buf) - ret;
ret = b_data(&outbuf);
b_add(buf, ret);
return ret;
}