On Thu, Nov 28, 2019 at 10:30:22AM +0100, Baptiste wrote:
> I am personally all confused by this report :)
> Furthermore, as mentioned the test on eb was already done.
> If the fix is to remove the useless test on res, then William's patch is
> right.
Here coverity assumes that if eb is not 0, it
On Wed, Nov 27, 2019 at 11:32:41PM +0100, William Dauchy wrote:
> `eb` being tested above, `res` cannot be null, so the condition is
> not needed and introduces potential dead code.
Now applied, thank you!
Willy
hello,
what do you think if we add something like that ?
--- a/reg-tests/ssl/wrong_ctx_storage.vtc
+++ b/reg-tests/ssl/wrong_ctx_storage.vtc
@@ -30,7 +30,7 @@ haproxy h1 -conf {
listen frt
mode http
${no-htx} option http-use-htx
-bind "fd@${frt}" ssl crt ${testdir}/common.pem
+
On 28 Nov 11:02, Baptiste wrote:
> On Thu, Nov 28, 2019 at 10:56 AM Julien Pivotto
> wrote:
>
> > On 28 Nov 10:38, Baptiste wrote:
> > > 'hold valid' still prevents HAProxy from changing the status of the
> > server
> > > in current Valid status to an other status for that period of time.
> > > I
On Thu, Nov 28, 2019 at 11:19:10AM +0100, Tim Düsterhus wrote:
> The commit message says:
>
> > This fix is only for 2.0 and older versions as legacy mode was
> > removed from 2.1. It should be backported to all maintained versions.
>
> Which is not 2.0 only, but 2.0 and older. Specifically the b
On 28 Nov 12:09, Julien Pivotto wrote:
> On 27 Nov 01:15, Илья Шипицин wrote:
> > ср, 27 нояб. 2019 г. в 01:10, Russell Eason :
> >
> > > Hello,
> > >
> > > Fedora upstream added it
> > > https://src.fedoraproject.org/rpms/haproxy/c/45c57ba71174f308a5f59569bac0598bb31ef767
> > > , and can be seen
On 27 Nov 01:15, Илья Шипицин wrote:
> ср, 27 нояб. 2019 г. в 01:10, Russell Eason :
>
> > Hello,
> >
> > Fedora upstream added it
> > https://src.fedoraproject.org/rpms/haproxy/c/45c57ba71174f308a5f59569bac0598bb31ef767
> > , and can be seen as far back as F24 here
> > https://src.fedoraproject.o
[removed people from Cc whom I don't believe are relevant any more]
Aleks,
Am 28.11.19 um 07:30 schrieb Aleksandar Lazic:
>> Sorry to bother you again but according to CVE-2019-18277 it says A flaw was
>> found in HAProxy before 2.0.6. So request you to please confirm whether all
>> versions wh
On Wed, Nov 27, 2019 at 05:10:10PM +0100, Emmanuel Hocdet wrote:
>
> Patches update, should address William’s comments.
>
Thanks, merged!
--
William Lallemand
Hello,
On Thu, Nov 28, 2019 at 10:35 AM Baptiste wrote:
>
> @Willy, since 1.8 (I think), the DNS task is autonomous and not triggered by
> the check anymore.
>
> Second, HAProxy never ever follows up TTLs.
>
> Third, I "fixed" a bug in 2.0.10 which triggers this change of behavior.
> Basically,
On Thu, Nov 28, 2019 at 10:56 AM Julien Pivotto
wrote:
> On 28 Nov 10:38, Baptiste wrote:
> > 'hold valid' still prevents HAProxy from changing the status of the
> server
> > in current Valid status to an other status for that period of time.
> > Imagine your server is UP, DNS is valid, then your
On 28 Nov 10:38, Baptiste wrote:
> 'hold valid' still prevents HAProxy from changing the status of the server
> in current Valid status to an other status for that period of time.
> Imagine your server is UP, DNS is valid, then your server returns NX for 2
> minutes, then the status of the server w
Le 15/11/2019 à 15:55, Pierre Cheynier a écrit :
* it's great to have new metrics (such as
`haproxy_process_current_zlib_memory`), but we also noticed that some very
useful ones were not present due to their type, example:
[ST_F_CHECK_STATUS] = IST("untyped"),
Hi Pierre,
Here is a patch to
'hold valid' still prevents HAProxy from changing the status of the server
in current Valid status to an other status for that period of time.
Imagine your server is UP, DNS is valid, then your server returns NX for 2
minutes, then the status of the server won't change. If NX is returned for
more t
@Willy, since 1.8 (I think), the DNS task is autonomous and not triggered
by the check anymore.
Second, HAProxy never ever follows up TTLs.
Third, I "fixed" a bug in 2.0.10 which triggers this change of behavior.
Basically, "timeout resolve" which is supposed to be the interval between 2
DNS reso
I am personally all confused by this report :)
Furthermore, as mentioned the test on eb was already done.
If the fix is to remove the useless test on res, then William's patch is
right.
(Thx for handling it William)
Baptiste
indeed it is checked earlier
https://github.com/haproxy/haproxy/blob/master/src/dns.c#L1574
чт, 28 нояб. 2019 г. в 12:18, William Dauchy :
> On Thu, Nov 28, 2019 at 11:10:34AM +0500, Илья Шипицин wrote:
> > Willy thinks it should be "eb" instead of "res"
>
> yup I saw that comment but I don't ge
17 matches
Mail list logo