Hi,
This is a friendly bot that watches fixes pending for the next haproxy-stable
release! One such e-mail is sent periodically once patches are waiting in the
last maintenance branch, and an ideal release date is computed based on the
severity of these fixes and their merge date. Responses
Hello list,
after unsuccessful search in the documentation I am asking here if it's
possible to somehow make HAProxy log the reason why a SSL handshake
failed (especially on a frontend).
I am thinking of logging the SSL alert message, for example logging if
the message came from the server or the
On Tue, Jun 23, 2020 at 06:56:08PM +0200, Tim Duesterhus wrote:
> Willy,
>
> realized I forgot to update the commit reference in the first patch after the
> change now is in cfgparse instead of tools, so here is v3. Only the commit
> message changed compared to v2.
Just in time :-)
Now merged,
The returned `arg` value is the number of arguments found, but in case
of the error message it's not a valid argument index.
Because we know how many arguments we allowed (MAX_LINE_ARGS) we know
what to print in the error message, so do just that.
Consider a configuration like this:
listen
The arguments are relative to the outline, not relative to the input line.
This patch fixes up commit 9e1758efbd68c8b1d27e17e2abee110f3ebe which
is 2.2 only. No backport needed.
---
src/cfgparse.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/cfgparse.c
Willy,
realized I forgot to update the commit reference in the first patch after the
change now is in cfgparse instead of tools, so here is v3. Only the commit
message changed compared to v2.
Best regards
Tim Düsterhus (2):
BUG/MINOR: cfgparse: Fix argument reference in PARSE_ERR_TOOMANY
Willy,
Am 23.06.20 um 17:37 schrieb Willy Tarreau:
> On Tue, Jun 23, 2020 at 05:06:27PM +0200, Tim Duesterhus wrote:
>> Otherwise `arg++` will be executed for every argument after the maximum,
>> returning a bogus value.
>
> No, it returns the correct one, as documented at the beginning of the
>
The returned `arg` value is the number of arguments found, but in case
of the error message it's not a valid argument index.
Because we know how many arguments we allowed (MAX_LINE_ARGS) we know
what to print in the error message, so do just that.
Consider a configuration like this:
listen
The arguments are relative to the outline, not relative to the input line.
This patch fixes up commit 9e1758efbd68c8b1d27e17e2abee110f3ebe which
is 2.2 only. No backport needed.
---
src/cfgparse.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/cfgparse.c
Hi Tim,
On Tue, Jun 23, 2020 at 05:06:27PM +0200, Tim Duesterhus wrote:
> Otherwise `arg++` will be executed for every argument after the maximum,
> returning a bogus value.
No, it returns the correct one, as documented at the beginning of the
function:
... are not updated beyond but the
The arguments are relative to the outline, not relative to the input line.
This patch fixes up commit 9e1758efbd68c8b1d27e17e2abee110f3ebe which
is 2.2 only. No backport needed.
---
src/cfgparse.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/cfgparse.c
Otherwise `arg++` will be executed for every argument after the maximum,
returning a bogus value.
Consider a configuration like this:
listen foo
1 2 3 [...] 64 65
Then running a configuration check within valgrind reports the following:
==18265== Conditional jump or move depends
12 matches
Mail list logo
