Hi Damien,
On Tue, Apr 09, 2024 at 03:37:07PM +, Damien Claisse wrote:
> We observed that a dynamic server which health check is down for longer
> than slowstart delay at startup doesn't trigger the warmup phase, it
> receives full traffic immediately. This has been confirmed by checking
>
We observed that a dynamic server which health check is down for longer
than slowstart delay at startup doesn't trigger the warmup phase, it
receives full traffic immediately. This has been confirmed by checking
haproxy UI, weight is immediately the full one (e.g. 75/75), without any
throttle
On Wed, Mar 27, 2024 at 02:34:25PM +, Damien Claisse wrote:
> When adding a server dynamically, we observe that when a backend has a
> dynamic persistence cookie, the new server has no cookie as we receive
> the following HTTP header:
> set-cookie: test-cookie=; Expires=Thu, 01-Jan-1970
When adding a server dynamically, we observe that when a backend has a
dynamic persistence cookie, the new server has no cookie as we receive
the following HTTP header:
set-cookie: test-cookie=; Expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/
Whereas we were expecting to receive something like the
On Fri, Mar 22, 2024 at 09:45:59AM +, Damien Claisse wrote:
> Hi Amaury!
> Sorry for the HTML message, I have to use a *** well-known enterprise MUA :(
> Le 22/03/2024 09:09, « Amaury Denoyelle » a écrit :
>> This patch raises several interrogations. First, dynamic servers are
>> currently
Hi Amaury!
Sorry for the HTML message, I have to use a *** well-known enterprise MUA :(
Le 22/03/2024 09:09, « Amaury Denoyelle » a écrit :
This patch raises several interrogations. First, dynamic servers are
currently intended to not support cookies, hence why the keyword is
disabled for
On Thu, Mar 21, 2024 at 02:37:06PM +, Damien Claisse wrote:
> When adding a server dynamically, we observe that when a backend has a
> dynamic persistence cookie, the new server has no cookie as we receive
> the following HTTP header:
> set-cookie: test-cookie=; Expires=Thu, 01-Jan-1970
When adding a server dynamically, we observe that when a backend has a
dynamic persistence cookie, the new server has no cookie as we receive
the following HTTP header:
set-cookie: test-cookie=; Expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/
Whereas we were expecting to receive something like the
Almost identical to 13e86d9 (BUG/MEDIUM: listener: Fix race condition
when updating the global mngmt task). When multiple `listener_accept`
threads attempt to schedule the proxy task which calls `manage_proxy`,
one listener thread may be sufficiently delayed to cause a race between
its call
The function `smp_fetch_ssl_fc_ec` gets the curve name used during key
exchange. It currently uses the `SSL_get_negotiated_group`,
available since OpenSSLv3.0 to get the nid and derive the short name of the
curve from the nid. In OpenSSLv3.2, a new function,
`SSL_get0_group_name` was added that
The function `smp_fetch_ssl_fc_ec` gets the curve name used during key
exchange. It currently uses the `SSL_get_negotiated_group`,
available since OpenSSLv3.0 to get the nid and derive the short name of the
curve from the nid. In OpenSSLv3.2, a new function,
`SSL_get0_group_name` was added that
Dear list!
Author: Steven Lu
Number of patches: 1
This is an automated relay of the Github pull request:
BUG/MEDIUM: server-state: update server if the ports in config and
state match
Patch title(s):
BUG/MEDIUM: server-state: Only update server if the ports in config and
state still
Previously an expression like:
path,word(2,/) -m found
always returned `true`.
Bug exists since the `word` converter exists. That is:
c9a0f6d0232cf44d6b08d1964b9097a45a6c65f0
The same bug was previously fixed for the `field` converter in commit
4381d26edc03faa46401eb0fe82fd7be84be14fd
On Sat, Sep 30, 2023 at 11:06:28PM +0200, Willy Tarreau wrote:
> On Sat, Sep 30, 2023 at 10:19:05AM +, Mathias Weiersmüller wrote:
> > Hi Willy,
> >
> > > Argh, thanks for notifying us! Haproxy dev5 crashed leaving a huge core
> > > that filled the FS (I hope it's complete, not checked yet),
On Sat, Sep 30, 2023 at 10:19:05AM +, Mathias Weiersmüller wrote:
> Hi Willy,
>
> > Argh, thanks for notifying us! Haproxy dev5 crashed leaving a huge core
> > that filled the FS (I hope it's complete, not checked yet), and the cron
> > job that rebuilds the bugs page miserably failed as you
Hi Willy,
> Argh, thanks for notifying us! Haproxy dev5 crashed leaving a huge core
> that filled the FS (I hope it's complete, not checked yet), and the cron
> job that rebuilds the bugs page miserably failed as you can see :-/
>
> That's now fixed, thank you!
> Willy
the links to the
Hi Lukas,
On Wed, Sep 27, 2023 at 09:49:53PM +, Lukas Tribus wrote:
> Hello,
>
> looks like the bug pages are broken; they contain the table of bugs
> but there is really no formatting happening and it appears the entire
> HTML header and footer is missing:
>
Hello,
And https://www.haproxy.org/bugs/index.html is an empty document.
There is a link for it on haproxy.org home page (as Known bugs).
Le 27/09/2023 à 23:49, Lukas Tribus a écrit :
Hello,
looks like the bug pages are broken; they contain the table of bugs
but there is really no formatting
Hello,
looks like the bug pages are broken; they contain the table of bugs
but there is really no formatting happening and it appears the entire
HTML header and footer is missing:
Example:
http://www.haproxy.org/bugs/bugs-2.4.html
http://www.haproxy.org/bugs/bugs-2.6.2.html
BR,
Lukas
Le 12/09/2023 à 11:37, Cedric Paillet a écrit :
When a server is in maintenance, the check.status is no longer updated. Therefore,
we shouldn't consider check.status if the checks are not active. This check was
properly implemented in the haproxy_server_check_status metric, but wasn't carried
When a server is in maintenance, the check.status is no longer updated.
Therefore, we shouldn't consider check.status if the checks are not active.
This check was properly implemented in the haproxy_server_check_status metric,
but wasn't carried over to backend_agg_check_status, which
ush it afterwards.
Thank you very much.
-Message d'origine-
De : Christopher Faulet
Envoyé : lundi 11 septembre 2023 20:15
À : Cedric Paillet ; haproxy@formilux.org
Objet : Re: [PATCH] BUG/MINOR: promex: don't count servers in maintenance
Le 07/09/2023 à 16:50, Cedric Paillet a écrit :
>
&g
Le 07/09/2023 à 16:50, Cedric Paillet a écrit :
And I guess we should also check the healthchecks are enabled for the server.
It is not really an issue because call to get_check_status_result() will
exclude neutral and unknown satuses. But there is no reason to count these
servers.
What
Le 11/09/2023 à 15:09, Cedric Paillet a écrit :
The state of servers that were put in maintenance via the runtime API are
reported within the "backend_agg_check_status" metric, which
lead to inconsistent sums when compared to the "haproxy_server_check_status"
metric.
Now excluding them from
The state of servers that were put in maintenance via the runtime API are
reported within the "backend_agg_check_status" metric, which
lead to inconsistent sums when compared to the "haproxy_server_check_status"
metric.
Now excluding them from this computation.
---
> I guess you mean "backend_add_check_status". Because
> "backend_agg_server_check_status" is a deprecated metric. It was replaced by
> "backend_agg_server_status".
Yes, sorry (and I should know, it's me who deprecated this value! )"
In this patch both will be up updated, as it's the same code
Hi,
Thanks Cedric and sorry for the delay. I have few comments.
Le 01/09/2023 à 08:22, Cedric Paillet a écrit :
The state of servers that were put in maintenance via the runtime API are
reported within the "backend_agg_server_check_status" metric, which
I guess you mean
Dear list!
Author: Chris Staite
Number of patches: 1
This is an automated relay of the Github pull request:
BUG/MEDIUM: h1-htx: Ensure chunked parsing with full output buffer
Patch title(s):
BUG/MEDIUM: h1-htx: Ensure chunked parsing with full output buffer
Link:
https://github.com
The state of servers that were put in maintenance via the runtime API are
reported within the "backend_agg_server_check_status" metric, which
lead to inconsistent sums when compared to the "haproxy_server_check_status"
metric.
Now excluding them from this computation.
---
On Thu, Aug 10, 2023 at 01:59:34PM +0200, Johannes Naab wrote:
> On 8/9/23 17:53, Aurelien DARRAGON wrote:
> >> "http-request sc-set-gpt" does work, so does "tcp-request session". I.e.
> >> the bug seems to depend on "tcp-request connection".
&
On 8/9/23 17:53, Aurelien DARRAGON wrote:
>> "http-request sc-set-gpt" does work, so does "tcp-request session". I.e.
>> the bug seems to depend on "tcp-request connection".
>>
>
> Indeed, according to both doc and code, sc-set-gpt and sc-set
>> I have no idea what causes it at the moment. A few things you could try,
>> in any order, to help locate the bug:
>>
>> - check if it accepts it using "http-request sc-set-gpt" instead of
>> "tcp-request connection" so that we know if it
nfig parsing with `internal error, unexpected rule->from=0,
>> please report this bug!`.
>
> At first glance I can't find a reason why your config would not work,
> so you've definitely discovered a bug.
>
> I have no idea what causes it at the moment. A few things you c
- update/set gpt0 if the current conn_rate is greater than what is stored in
> the gpt.
>
> But I have trouble setting the gpt even from a trivial sample expression,
> erroring during config parsing with `internal error, unexpected rule->from=0,
> please report this bug!`.
At fi
setting the gpt even from a trivial sample expression,
erroring during config parsing with `internal error, unexpected rule->from=0,
please report this bug!`.
Config, output, and haproxy -vv below.
Should this work, or do I misunderstand what sc-set-gpt can achieve?
Best regards,
Johan
Le 7/20/23 à 22:21, Marcos de Oliveira a écrit :
From: Marcos de Oliveira
On a clean installation, users might want to use server-state-file and
the recommended zero-warning option. This caused a problem if
server-state-file was not found, as a warning was emited, causing
startup to fail.
From: Marcos de Oliveira
On a clean installation, users might want to use server-state-file and
the recommended zero-warning option. This caused a problem if
server-state-file was not found, as a warning was emited, causing
startup to fail.
This will allow users to specify nonexistent
From: Marcos de Oliveira
Users might want to pre-create an empty file for later dumping
server-states. This commit allows for that by emiting a notice in case
file is empty and a warning if file is not empty, but version is unknown
Fix partially: #2190
---
src/server_state.c | 23
On Fri, Jun 02, 2023 at 10:11:36AM +0200, Tim Düsterhus wrote:
> Hi
>
> On 6/2/23 08:42, Willy Tarreau wrote:
> > Thank you for this. I've added a comment in the file about it, and a
> > regtest to detect when this happens, since (null) appears in the header
> > line of the "show stat" output in
Hi
On 6/2/23 08:42, Willy Tarreau wrote:
Thank you for this. I've added a comment in the file about it, and a
regtest to detect when this happens, since (null) appears in the header
line of the "show stat" output in this case.
Nice, thank you. I thought about including a test for that, but
Hi Tim,
On Thu, Jun 01, 2023 at 06:58:08PM +0200, Tim Duesterhus wrote:
> Lua's `get_stats` function stopped working in
> 4cfb0019e65bce79953164eddf54c1bbb61add62, due to the addition a new field
> ST_F_PROTO without a corresponding entry in `stat_fields`.
Thank you for this. I've added a
Lua's `get_stats` function stopped working in
4cfb0019e65bce79953164eddf54c1bbb61add62, due to the addition a new field
ST_F_PROTO without a corresponding entry in `stat_fields`.
Fix the issue by adding the entry, like
a46b142e8807ea640e041d3a29e3fd427844d559 did previously for a different field.
Dear haproxy maintainers：
if we should add check for memory allocation?
I got 3 coredumps(haproxy version is 2.6.6):
bt 1
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x7f0a03a50a57 in BIO_meth_set_write (biom=0x0,
bwrite=bwrite@entry=0x55fbf4ac5260 ) at
On Sun, Apr 23, 2023 at 02:25:06PM +0200, Lukas Tribus wrote:
> On Sun, 23 Apr 2023 at 13:08, Willy Tarreau wrote:
> >
> > On Sun, Apr 23, 2023 at 12:39:25PM +0200, Tim Düsterhus, WoltLab GmbH wrote:
> > > Willy,
> > >
> > > On 3/27/23 20:25, Willy Tarreau wrote:
> > > > OK, let's see what other
On Sun, 23 Apr 2023 at 13:08, Willy Tarreau wrote:
>
> On Sun, Apr 23, 2023 at 12:39:25PM +0200, Tim Düsterhus, WoltLab GmbH wrote:
> > Willy,
> >
> > On 3/27/23 20:25, Willy Tarreau wrote:
> > > OK, let's see what other users and participants think about it. If I get
> > > at least one "please
On Sun, Apr 23, 2023 at 12:39:25PM +0200, Tim Düsterhus, WoltLab GmbH wrote:
> Willy,
>
> On 3/27/23 20:25, Willy Tarreau wrote:
> > OK, let's see what other users and participants think about it. If I get
> > at least one "please don't change it" I'll abide, otherwise it may make
> > sense to
Willy,
On 3/27/23 20:25, Willy Tarreau wrote:
OK, let's see what other users and participants think about it. If I get
at least one "please don't change it" I'll abide, otherwise it may make
sense to fix it before it ossifies and annoys some future users.
Anyone has any opinion here ?
Wanted
On Mon, Mar 27, 2023 at 03:43:22PM +0200, Remi Tricot-Le Breton wrote:
>
> On 27/03/2023 15:31, Tim Düsterhus wrote:
> > Hi
> >
> > On 3/19/23 16:07, Tim Duesterhus wrote:
> >> Previously performing a config check of `.github/h2spec.config` would
> >> report a
> >> 20 byte leak as reported in
On Mon, Mar 27, 2023 at 07:08:24PM +0200, Tim Düsterhus, WoltLab GmbH wrote:
> Willy,
>
> On 3/27/23 18:17, Willy Tarreau wrote:
> > Hmmm that's embarrassing indeed. On the one hand we should consider
> > that it's part of the visible API and should stay like this eternally
> > (like "Referer" in
Willy,
On 3/27/23 18:17, Willy Tarreau wrote:
Hmmm that's embarrassing indeed. On the one hand we should consider
that it's part of the visible API and should stay like this eternally
(like "Referer" in HTTP). On the other hand, it was introduced only in
2.3, splicing is not the most commonly
Hi Tim,
On Mon, Mar 27, 2023 at 03:26:51PM +0200, Tim Düsterhus, WoltLab GmbH wrote:
> From d1c3bd09b95e6f68d8dc849b0637088b79856fbc Mon Sep 17 00:00:00 2001
> From: Tim Duesterhus
> Date: Mon, 27 Mar 2023 15:23:44 +0200
> Subject: [PATCH] BUG/MINOR: Fix typo in `TotalSplicedBytesOut
On 27/03/2023 15:31, Tim Düsterhus wrote:
Hi
On 3/19/23 16:07, Tim Duesterhus wrote:
Previously performing a config check of `.github/h2spec.config` would
report a
20 byte leak as reported in GitHub Issue #2082.
The leak was introduced in a6c0a59e9af65180c3ff591b91855bea8d19b352,
which is
Hi
On 3/19/23 16:07, Tim Duesterhus wrote:
Previously performing a config check of `.github/h2spec.config` would report a
20 byte leak as reported in GitHub Issue #2082.
The leak was introduced in a6c0a59e9af65180c3ff591b91855bea8d19b352, which is
dev only. No backport needed.
I believe you
Managing director:
Marcel Werk
AG Potsdam HRB 26795 PFrom d1c3bd09b95e6f68d8dc849b0637088b79856fbc Mon Sep 17 00:00:00 2001
From: Tim Duesterhus
Date: Mon, 27 Mar 2023 15:23:44 +0200
Subject: [PATCH] BUG/MINOR: Fix typo in `TotalSplicedBytesOut` field name
To: haproxy@formilux.org
Cc: w...@1wt.eu
On Wed, Mar 22, 2023 at 02:39:15PM +0100, Miroslav Zagorac wrote:
> On 22. 03. 2023. 14:33, Willy Tarreau wrote:
> >> Also, in that case, when calling 'haproxy -vv', it is no longer printed
> >> that
> >> malloc_trim is enabled.
> >
> > I'm not sure what you mean here, because for me it's never
On 22. 03. 2023. 14:33, Willy Tarreau wrote:
>> Also, in that case, when calling 'haproxy -vv', it is no longer printed that
>> malloc_trim is enabled.
>
> I'm not sure what you mean here, because for me it's never printed that
> malloc_trim() is enabled when building with jemalloc.
>
Hello
Hi Miroslav,
On Wed, Mar 22, 2023 at 01:11:53PM +0100, Miroslav Zagorac wrote:
> Hello all,
>
> here is a patch that does not allow the use of malloc_trim() function if
> HAProxy is linked with the malloc library. It was checked in some places in
> the source, but not everywhere.
Oh thanks for
On 22. 03. 2023. 13:11, Miroslav Zagorac wrote:
> Hello all,
>
> here is a patch that does not allow the use of malloc_trim() function if
> HAProxy is linked with the malloc library. It was checked in some places in
.. jemalloc .., sorry for the typo.
> the source, but not everywhere.
>
>
.
--
Miroslav Zagorac
Senior DeveloperFrom 33a84d19548baf46e8fccbb58a891a3e4c6b4895 Mon Sep 17 00:00:00 2001
From: Miroslav Zagorac
Date: Wed, 22 Mar 2023 12:52:19 +0100
Subject: [PATCH] BUG/MINOR: illegal use of the malloc_trim() function if
jemalloc is used
In the event that HAProxy is linked
Previously performing a config check of `.github/h2spec.config` would report a
20 byte leak as reported in GitHub Issue #2082.
The leak was introduced in a6c0a59e9af65180c3ff591b91855bea8d19b352, which is
dev only. No backport needed.
---
src/ssl_sock.c | 2 ++
1 file changed, 2 insertions(+)
Hi Oto!
On Wed, Mar 01, 2023 at 01:23:02PM +0100, PR Bot wrote:
> Dear list!
>
> Author: Oto Valek
> Number of patches: 2
>
> This is an automated relay of the Github pull request:
>BUG/MINOR: http-fetch: recognize IPv6 addresses in square brackets in
>req.hdr
Dear list!
Author: Oto Valek
Number of patches: 2
This is an automated relay of the Github pull request:
BUG/MINOR: http-fetch: recognize IPv6 addresses in square brackets in
req.hdr_ip()
Patch title(s):
BUG/MINOR: http-fetch: recognize IPv6 addresses in square brackets
Dear list!
Author: Oto Valek
Number of patches: 2
This is an automated relay of the Github pull request:
BUG/MINOR: http-fetch: recognize IPv6 addresses in square brackets in
req.hdr_ip()
Patch title(s):
BUG/MINOR: http-fetch: recognize IPv6 addresses in square brackets
On Tue, Jan 17, 2023 at 09:44:11AM +1100, Paul Barnetta wrote:
> Existing logic for checking whether a regex subexpression for pathinfo
> is matched results in valid matches being ignored and non-matches having
> a new zero length string stored in params->pathinfo. This patch reverses
> the logic
Existing logic for checking whether a regex subexpression for pathinfo
is matched results in valid matches being ignored and non-matches having
a new zero length string stored in params->pathinfo. This patch reverses
the logic so params->pathinfo is set when the subexpression is matched.
Without
Hi Bertrand,
On Sat, Dec 17, 2022 at 09:39:38PM +, Bertrand Jacquin wrote:
> testdir can be a very long directory since it depends on source
> directory path, this can lead to failure during tests when UNIX socket
> path exceeds maximum allowed length of 97 characters as defined in
>
testdir can be a very long directory since it depends on source
directory path, this can lead to failure during tests when UNIX socket
path exceeds maximum allowed length of 97 characters as defined in
str2sa_range().
16:48:14 [ALERT] *** h1debug|(10082) : config : parsing
Paillet (2):
BUG/MINOR: promex: create haproxy_backend_agg_server_status
MINOR: promex: introduce haproxy_backend_agg_check_status
addons/promex/service-prometheus.c | 30 +-
include/haproxy/stats-t.h | 2 ++
src/stats.c| 10
haproxy_backend_agg_server_check_status currently aggregates
haproxy_server_status instead of haproxy_server_check_status.
We deprecate this and create a new one,
haproxy_backend_agg_server_status to clarify what it really
does.
---
addons/promex/service-prometheus.c | 4 +++-
haproxy_backend_agg_server_status metric, aggregation of
haproxy_backend_server_status. (to replace misnamed
haproxy_backend_agg_server_check_status)
- create new haproxy_backend_agg_check_status metric, aggregation of
haproxy_backend_server_check_status.
Cedric Paillet (2):
BUG/MINOR: promex: create
Le 12/6/22 à 15:13, Cedric Paillet a écrit :
Sorry, indeed I mentioned the enum ID and not the promex name.
I proposed to keep "haproxy_bakcned_agg_server_check_status"
altering its description to announce it is deprecated
. And then to add "haproxy_backend_agg_check_status"
aggregate
>Sorry, indeed I mentioned the enum ID and not the promex name.
>I proposed to keep "haproxy_bakcned_agg_server_check_status"
> altering its description to announce it is deprecated
>. And then to add "haproxy_backend_agg_check_status"
>aggregate haproxy_server_check_status) and
On Tue, Dec 6, 2022 at 3:27 AM Christopher Faulet wrote:
> IMHO, we should keep the current metric and its description should be updated
> to
> mention it is deprecated. This way, we will be able to remove it in the 2.9 or
> 3.0. This means we should find new names for the aggregated servers
Le 12/6/22 à 12:26, Cedric Paillet a écrit :
Sorry for the delay. We were busy because of the 2.7.0 and then I forgot your
patches :) And it was a bit late to add it into the 2.7.0.
No problem.
Because the metric name is indeed badly chosen but we can't break the
compatibility, especially
> Sorry for the delay. We were busy because of the 2.7.0 and then I forgot your
> patches :) And it was a bit late to add it into the 2.7.0.
No problem.
> Because the metric name is indeed badly chosen but we can't break the
> compatibility, especially in a LTS version.
Ok, I understand that.
to
haproxy_backend_agg_server_status and use right data source for
haproxy_backend_agg_server_check_status.
Cedric Paillet (2):
BUG/MINOR: promex: rename haproxy_backend_agg_server_check_status
MINOR: promex: reintroduce haproxy_backend_agg_server_check_status
addons/promex/service-prometheus.c | 28
Envoyé : mardi 29 novembre 2022 12:39
À : Cedric Paillet
Cc : haproxy@formilux.org; Christopher Faulet
Objet : Re: [PATCH 0/2] BUG/MINOR: promex: fix
haproxy_backend_agg_server_check_status
On Tue, Nov 29, 2022 at 11:52 AM William Dauchy wrote:
> On Mon, Nov 28, 2022 at 8:46 AM Cedric Pail
On Tue, Nov 29, 2022 at 11:52 AM William Dauchy wrote:
> On Mon, Nov 28, 2022 at 8:46 AM Cedric Paillet wrote:
> > As described in github issue #1312, the first intention of patch 42d7c402d
> > was to aggregate haproxy_server_check_status. But we aggregated
> > haproxy_server_status instead.
> >
Hello Cedric,
On Mon, Nov 28, 2022 at 8:46 AM Cedric Paillet wrote:
> As described in github issue #1312, the first intention of patch 42d7c402d
> was to aggregate haproxy_server_check_status. But we aggregated
> haproxy_server_status instead.
> To fix that, rename
haproxy_backend_agg_server_check_status currently aggregates
haproxy_server_status instead of haproxy_server_check_status.
Rename the metric to haproxy_backend_agg_server_status to
clarify what it really does.
---
addons/promex/service-prometheus.c | 4 ++--
include/haproxy/stats-t.h | 2
for
haproxy_backend_agg_server_check_status.
Cedric Paillet (2):
BUG/MINOR: promex: rename haproxy_backend_agg_server_check_status
MINOR: promex: reintroduce haproxy_backend_agg_server_check_status
addons/promex/service-prometheus.c | 28 +++-
include/haproxy/stats-t.h
Le 9/26/22 à 17:27, Fatih Acar a écrit :
This patch adds support to the following authentication methods:
- AUTH_REQ_GSS (7)
- AUTH_REQ_SSPI (9)
- AUTH_REQ_SASL (10)
Note that since AUTH_REQ_SASL allows multiple authentication mechanisms
such as SCRAM-SHA-256 or SCRAM-SHA-256-PLUS, the auth
Le 9/26/22 à 17:27, Fatih Acar a écrit :
This patch adds support to the following authentication methods:
- AUTH_REQ_GSS (7)
- AUTH_REQ_SSPI (9)
- AUTH_REQ_SASL (10)
Note that since AUTH_REQ_SASL allows multiple authentication mechanisms
such as SCRAM-SHA-256 or SCRAM-SHA-256-PLUS, the auth
This patch adds support to the following authentication methods:
- AUTH_REQ_GSS (7)
- AUTH_REQ_SSPI (9)
- AUTH_REQ_SASL (10)
Note that since AUTH_REQ_SASL allows multiple authentication mechanisms
such as SCRAM-SHA-256 or SCRAM-SHA-256-PLUS, the auth payload length may
vary since the method is
On Wed, Aug 17, 2022 at 01:05:55PM +, Mateusz Malek wrote:
> On 17.08.2022 14:59, Mateusz Malek wrote:
> > Sure - here you go:
>
> Sorry, wrong file. Patch in previous email had a typo (double /req9
> call instead of /req9 and /req10) in VTest test case.
Perfect, thank you, now applied!
?UTF-8?q?Mateusz=20Ma=C5=82ek?=
Date: Wed, 17 Aug 2022 14:22:09 +0200
Subject: [PATCH] BUG/MEDIUM: http-ana: fix crash or wrong header deletion by
http-restrict-req-hdr-names
When using `option http-restrict-req-hdr-names delete`, HAproxy may
crash or delete wrong header after receiving r
06aff2289776883915d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mateusz=20Ma=C5=82ek?=
Date: Wed, 17 Aug 2022 14:22:09 +0200
Subject: [PATCH] BUG/MEDIUM: http-ana: fix crash or wrong header deletion by
http-restrict-req-hdr-names
When using `option http-restrict-req-hdr-names delete`, HAproxy may
c
t; still marked as `status: needs-triage`. I think MEDIUM would be
> appropriate.
Yes I think so as well.
> By the way, while writing VTest to cover this bug, I spotted something
> "suspicious" about reg tests for FCGI backends - my-fcgi-app FCGI app is
> defined, but it i
htx_get_next_blk if preserve_blk is set
or call htx_remove_blk otherwise
I have not included severity of the patch, because on GitHub issue is
still marked as `status: needs-triage`. I think MEDIUM would be
appropriate.
By the way, while writing VTest to cover this bug, I spotted something
"suspicious&q
On Wed, May 25, 2022 at 10:58:51PM -0600, astrotha...@gmail.com wrote:
> From: Thayne McCombs
>
> Adjust the size of the sample buffer before we change the "area"
> pointer. Otherwise, we end up not changing the size, because the area
> pointer is already the same as "start" before we compute
From: Thayne McCombs
Adjust the size of the sample buffer before we change the "area"
pointer. Otherwise, we end up not changing the size, because the area
pointer is already the same as "start" before we compute the difference
between the two.
This is similar to the change in
Thanks for catching that.
On Sun, May 22, 2022 at 01:06:27PM +0200, Tim Duesterhus wrote:
> The given size must be the size of the destination buffer, not the size of the
> (binary) address representation.
>
> This fixes GitHub issue #1599.
>
> The bug was introduced in 92149f9a82a9b55c598f1cc815bc
The given size must be the size of the destination buffer, not the size of the
(binary) address representation.
This fixes GitHub issue #1599.
The bug was introduced in 92149f9a82a9b55c598f1cc815bc330c555f3561 which is in
2.4+. The fix must be backported there.
---
src/tools.c | 2 +-
1 file
Le 5/10/22 à 19:47, Boyang Li a écrit :
Lua API Channel.remove() and HTTPMessage.remove() expects 1 to 3
arguments (counting the manipulated object), with offset and length
being the 2nd and 3rd argument, respectively.
hlua_{channel,http_msg}_del_data() incorrectly gets the 3rd argument as
Lua API Channel.remove() and HTTPMessage.remove() expects 1 to 3
arguments (counting the manipulated object), with offset and length
being the 2nd and 3rd argument, respectively.
hlua_{channel,http_msg}_del_data() incorrectly gets the 3rd argument as
offset, and 4th (nonexistent) as length.
On Tue, Apr 26, 2022 at 11:28:47PM +0200, Tim Duesterhus wrote:
> A config like the following:
>
> global
> stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd
> listeners
>
> resolvers unbound
> nameserver unbound 127.0.0.1:53
>
> will report the following
A config like the following:
global
stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd
listeners
resolvers unbound
nameserver unbound 127.0.0.1:53
will report the following leak when running a configuration check:
==241882== 6,991 (6,952 direct, 39
On Sun, Apr 10, 2022 at 12:25:54PM -0600, Shawn Heisey wrote:
> On the dark mode stats page served by version 2.6-dev5, the frontend or
> backend description is grey text on a white background. It's very hard to
> read.
Ah indeed, a "th.desc" entry was missing to replace the background,
now
On the dark mode stats page served by version 2.6-dev5, the frontend or
backend description is grey text on a white background. It's very hard
to read.
This problem can't be seen on stats.haproxy.org, possibly because the
frontend and backend configs do not have any descriptions.
Thanks,
1 - 100 of 2099 matches
Mail list logo
