Re: fronted/bind ordering

On Sat, Nov 14, 2020 at 02:11:41AM +0100, Lukas Tribus wrote: > I'm afraid noreuseport is a global option in haproxy. Ah, bad, I thought we had it per bind line! > But the noreuseport was merely a suggestion to confirm that the kernel > is not OK with this config. OK. > The change in behavior

Re: fronted/bind ordering

Hello, On Fri, 13 Nov 2020 at 21:21, Willy Tarreau wrote: > > > I'd suggest you run haproxy with noreuseport [1] temporarily, and > > > check if your kernel refuses to bind() to those IP's - it likely will. > > > This indicates an unsupported configuration (by your kernel, not by > > >

[ANNOUNCE] haproxy-2.3.1

Hi, HAProxy 2.3.1 was released on 2020/11/13. It added 26 new commits after version 2.3.0. This is the first release since the 2.3.0 of last week and it fixes a few bugs: Chistopher fixed a memory corruption in the spoe which appears when an offloaded stream try to update the state of a

[PATCH] simplify openssl async detection

Hi. next define improvement. Ilya From 8c19da08c5ca3e389871733726f54a83d77b29f3 Mon Sep 17 00:00:00 2001 From: Ilya Shipitsin Date: Sat, 14 Nov 2020 01:56:34 +0500 Subject: [PATCH] BUILD: ssl: use SSL_MODE_ASYNC macro instead of OPENSSL_VERSION --- include/haproxy/openssl-compat.h | 2 +-

Re: fronted/bind ordering

Hi all, sorry for being late here. On Fri, Nov 13, 2020 at 04:08:18PM +0100, Bartosz wrote: > > I don't think you can setup sockets this way, I think this is an > > incorrect configuration leading to undefined behavior. The fact the > > behavior then changes across different kernels is not a

[PATCH] CI: Make the h2spec workflow more consistent with the VTest workflow

This PR aims to make the workflow more consistent, by reusing the same wording for the step names and the same commands to make it look like the vtest workflow as much as possible. It was renamed to compliance.yml to match the human readable name better. This also allows to extend the workflow

Re: [PATCH] REGTESTS: Add sample_fetches/cook.vtc

Le 13/11/2020 à 19:36, Tim Duesterhus a écrit : Add a reg-test verifying the fix in dea7c209f8a77b471323dd97bdc1ac4d7a17b812. Thanks Tim! merged now. -- Christopher Faulet

[PATCH] REGTESTS: Add sample_fetches/cook.vtc

Add a reg-test verifying the fix in dea7c209f8a77b471323dd97bdc1ac4d7a17b812. Some parts of the configuration used in the were taken from the initial bug report from Maciej. Should be backported together with dea7c209f8a77b471323dd97bdc1ac4d7a17b812 (all stable versions). Co-authored-by: Maciej

Re: [2.0.17] crash with coredump

Le 11/11/2020 à 12:43, Maciej Zdeb a écrit : Wow! Yes, I can confirm that a crash does not occur now. :) I checked 2.0 and 2.2 branches. I'll keep testing it for a couple days just to be sure. So that stacktrace I shared before (on spoe_release_appctx function) was very lucky... Do you think

Re: [PATCH] BUG/MINOR: http-htx: make sure to print warn on c-l error

Le 13/11/2020 à 13:35, William Dauchy a écrit : Hello Christopher, On Fri, Nov 13, 2020 at 11:14 AM Christopher Faulet wrote: After testing, the 2.1 and 2.0 are not affected because the warning is handled by the main parsing function cfg_parse_listen(). Or I missed something :) indeed I did

Re: HTTP fetch req.cook_cnt() always return 0

Le 13/11/2020 à 14:32, Maciej Zdeb a écrit : It is great Christopher! :) Thank you for fixing it! Ok, pushed and backported as far as 2.0. Thanks Maciej. -- Christopher Faulet

Re: fronted/bind ordering

Hi Lukas, thank you for your response. Lukas Tribus wrote on 13/11/2020 13:24 +0100: > Hello Bartosz, > > On Fri, 13 Nov 2020 at 10:08, Bartosz > wrote: > > > > Are we really the only ones with this issue? Has no one else seen this > > change in behaviour? Or otherwise have any idea where it's

Re: HTTP fetch req.cook_cnt() always return 0

It is great Christopher! :) Thank you for fixing it! W dniu pt., 13.11.2020 o 14:06 Christopher Faulet napisał(a): > Le 13/11/2020 à 11:27, Maciej Zdeb a écrit : > > Fixed warnings during compilation and fixed req.cook() which should > return first > > and not last value when no cookie name

Re: HTTP fetch req.cook_cnt() always return 0

Le 13/11/2020 à 11:27, Maciej Zdeb a écrit : Fixed warnings during compilation and fixed req.cook() which should return first and not last value when no cookie name specified. Thanks Maciej, I slightly updated your patch though. I changed the commit message to add details and simplified

Re: [PATCH] BUG/MINOR: http-htx: make sure to print warn on c-l error

Hello Christopher, On Fri, Nov 13, 2020 at 11:14 AM Christopher Faulet wrote: > After testing, the 2.1 and 2.0 are not affected because the warning is handled > by the main parsing function cfg_parse_listen(). Or I missed something :) indeed I did not test en 2.1 and 2.0 but only on 2.2 relying

Re: Add 401, 403 retries at l7

On 13 Nov 00:12, Jonathan Matthews wrote: > On Thu, 12 Nov 2020 at 12:21, Julien Pivotto wrote: > > > Dear, > > > > Please find a patch to add 401 and 403 l7 retries, see > > https://github.com/haproxy/haproxy/issues/948 > > > Hey Julien, > > This really feels like an anti-feature, to be

Re: fronted/bind ordering

Hello Bartosz, On Fri, 13 Nov 2020 at 10:08, Bartosz wrote: > > Are we really the only ones with this issue? Has no one else seen this > change in behaviour? Or otherwise have any idea where it's coming from? > > Or at least confirm whether they do or don't see the same behaviour. I don't think

Re: Integration of modsecurity v3 with haproxy

On 10.11.20 17:52, Thomas SIMON wrote: > Hi all, > > Is there a way to use some mecanism (spoe or other) to use modsecurity v3 > with haproxy (2.x) ? > I found documentation on modsecurity v2 integration with spoe , but nothing > on v3. > > My goal is to protect backends with modsecurity using

Re: HTTP fetch req.cook_cnt() always return 0

Fixed warnings during compilation and fixed req.cook() which should return first and not last value when no cookie name specified. pt., 13 lis 2020 o 10:48 Maciej Zdeb napisał(a): > I've a patch that is fixing the issue (I hope) ;) It's my first patch so > any hints are very welcome :) > > pt.,

Re: [PATCH] BUG/MINOR: http-htx: make sure to print warn on c-l error

Le 11/11/2020 à 14:23, William Dauchy a écrit : commit "BUG/MINOR: http-htx: Just warn if payload of an errorfile doesn't match the C-L" (which is only present in 2.2, 2.1 and 2.0 trees, i.e see commit 7bf3d81d3cf4b9f4587 in 2.2 tree), is changing the behavior of `http_str_to_htx` function as

Re: HTTP fetch req.cook_cnt() always return 0

I've a patch that is fixing the issue (I hope) ;) It's my first patch so any hints are very welcome :) pt., 13 lis 2020 o 09:45 Christopher Faulet napisał(a): > Le 12/11/2020 à 15:08, Maciej Zdeb a écrit : > > Hi, > > > > With such sample config: > > > > frontend front > > mode http > >

Re: fetching layer 7 samples with tcp mode frontend

Le 13/11/2020 à 09:59, Dmitry Sivachenko a écrit : Hello! Consider the following config excerpt: frontend test-fe mode tcp use_backend test-be1 if { path -i -m end /set } What is the notion of "path" sample at frontend working in TCP mode? We experimented with haproxy-1.5.18 on

Re: fronted/bind ordering

Are we really the only ones with this issue? Has no one else seen this change in behaviour? Or otherwise have any idea where it's coming from? Or at least confirm whether they do or don't see the same behaviour. Any pointers or suggestions will be appreciated. Kind regards, Bartosz Bartosz

fetching layer 7 samples with tcp mode frontend

Hello! Consider the following config excerpt: frontend test-fe mode tcp use_backend test-be1 if { path -i -m end /set } What is the notion of "path" sample at frontend working in TCP mode? We experimented with haproxy-1.5.18 on Linux sending HTTP queries with path ending with "/set"

Re: HTTP fetch req.cook_cnt() always return 0

Le 12/11/2020 à 15:08, Maciej Zdeb a écrit : Hi, With such sample config: frontend front     mode http     http-request set-var(txn.abc) req.cook_cnt()     http-response set-header abc %[var(txn.abc)]     bind x.x.x.x:80     default_backend back backend back     mode http     server srv