Re: HAProxy returning 502 with SH--

On Fri, 23 Aug 2024 at 18:55, BJ Taylor wrote: > > We are trying to deploy HAProxy into our environment. We have a script that > does some 600k api calls during approximately 24 hours. How many concurrent connections / transactions though? > During that time, when haproxy is in place, there ar

Re: [PATCH 0/2] Add MPTCP to haproxy

On 23/08/2024 17:20, Willy Tarreau wrote: > On Fri, Aug 23, 2024 at 05:11:11PM +0200, Matthieu Baerts wrote: (...) >> Maybe a new socket option would be better if the idea is only to >> silently drop connections? :) > > Yes, probably. Right now it's done directly in the action itself > (tcp_exec

Re: [PATCH 0/2] Add MPTCP to haproxy

On Fri, Aug 23, 2024 at 05:11:11PM +0200, Matthieu Baerts wrote: > >>> With that said, from an implementation perspective, it would seem right > >>> to make sure that most TCP tunables also work with MPTCP. > >> > >> That's what we tried to do. All "common" ones are supported, but it is > >> not al

Re: [PATCH 0/2] Add MPTCP to haproxy

On 23/08/2024 16:42, Willy Tarreau wrote: > On Fri, Aug 23, 2024 at 04:13:16PM +0200, Matthieu Baerts wrote: (...) >>> I'll comment on each patch separately, >> >> Thank you, please take your time! > > That's what I'm doing but I really want to make sure we won't discover > last-minute show-stop

Re: [PATCH 2/2] BUG/MINOR: fix warning when setting MSS with MPTCP

On Fri, Aug 23, 2024 at 04:50:33PM +0200, Willy Tarreau wrote: > > @@ -494,6 +498,30 @@ static void sock_inet_prepare() > > #endif > > close(fd); > > } > > + > > +#ifdef __linux__ > > Here I think a short comment is deserved to explain why __linux__, because > it's the same choice

Re: [PATCH 2/2] BUG/MINOR: fix warning when setting MSS with MPTCP

On Fri, Aug 23, 2024 at 03:34:10PM +0200, Aperence wrote: > Currently, the TCP_MAXSEG socket option doesn't seem to be supported > with MPTCP. This results in a warning when trying to set the MSS of > sockets in proto_tcp:tcp_bind_listener. > > This can be resolved by adding two new variables: > s

Re: [PATCH 0/2] Add MPTCP to haproxy

Hi Matthieu, On Fri, Aug 23, 2024 at 04:13:16PM +0200, Matthieu Baerts wrote: > Hi Willy, > > Thank you for your quick reply! You're welcome! > > I'll comment on each patch separately, > > Thank you, please take your time! That's what I'm doing but I really want to make sure we won't discover

Re: [PATCH 1/2] FEATURE: add MPTCP per address support

t; Note that this is a re-implementation of Björn's work from 3 years ago > [4], when haproxy's internals were probably less ready to deal with > this, causing his work to be left pending for a while. Thanks for mentioning his initial work! > diff --git a/include/haproxy/comp

Re: [PATCH 0/2] Add MPTCP to haproxy

Hi Willy, Thank you for your quick reply! On 23/08/2024 15:58, Willy Tarreau wrote: > On Fri, Aug 23, 2024 at 03:34:08PM +0200, Aperence wrote: (...) > I'll comment on each patch separately, Thank you, please take your time! > though I'll respond to the > question below: > >> - Patch 2: >>

Re: [PATCH 0/2] Add MPTCP to haproxy

Hello! On Fri, Aug 23, 2024 at 03:34:08PM +0200, Aperence wrote: > Multipath TCP (MPTCP), standardized in RFC8684 [1], is a TCP extension > that enables a TCP connection to use different paths. > > Multipath TCP has been used for several use cases. On smartphones, MPTCP > enables seamless handove

Re: minor patch to add environment variables for http and tcp clf log formats

to override the > + default log format without having to copy the whole original definition. For the doc we wap the lines at 80 chars so that they render correctly in default window sizes. I've re-justified the 3 lines. > --- a/src/haproxy.c > +++ b/src/haproxy.c >

Re: [PATCH] BUG/MINOR: stats-html: improve markup and fix css in dark mode

On Tue, Aug 20, 2024 at 03:29:04PM +0200, Nicolas CARPi wrote: > Hi Willy, > > On 20 Aug, Willy Tarreau wrote: > > Normally it's preferable to make one commit per functional change. > Noted. Here are three patches then. I've taken care of explaining the > reasoning behind each of these changes i

Re: [PATCH] BUG/MINOR: stats-html: improve markup and fix css in dark mode

Hi Willy, On 20 Aug, Willy Tarreau wrote: > Normally it's preferable to make one commit per functional change. Noted. Here are three patches then. I've taken care of explaining the reasoning behind each of these changes in the commit messages, which should answer your interrogations! :) Cheers

Re: [PATCH] BUG/MINOR: stats-html: improve markup and fix css in dark mode

Hi Nicolas, On Tue, Aug 20, 2024 at 11:08:33AM +0200, Nicolas CARPi wrote: > From 96f5e7951995be8216ecee81968b0f2c7fe0141a Mon Sep 17 00:00:00 2001 > From: Nicolas CARPi > Date: Tue, 20 Aug 2024 10:39:17 +0200 > Subject: [PATCH] BUG/MINOR: stats-html: improve markup and fix css in dark > mode >

Re: New option tcplog clf format

Hi Nathan, On Tue, Aug 13, 2024 at 06:34:00PM +, Nathan Wehrman wrote: > > Hello, > > For your consideration I wrote and tested a new a logging format that will > allow tcp mode proxies to send logs that will adhere to clf (common log > format). > This will allow the sending of that data to

Re: [PATCH] DOC: fix incorrect english in lua.txt

Hi Nicolas, On Wed, Aug 14, 2024 at 11:16:31AM +0200, Nicolas CARPi wrote: > From f9cff910630851658a9f126caf1009e08dec Mon Sep 17 00:00:00 2001 > From: Nicolas CARPi > Date: Tue, 13 Aug 2024 22:57:56 +0200 > Subject: [PATCH] DOC: fix incorrect english in lua.txt > > This commit fixes some ty

Re: [PATCH 1/3] CI: QUIC Interop LibreSSL: document chacha20 test status

On Tue, Aug 13, 2024 at 09:11:28PM +0200, Ilia Shipitsin wrote: > due to https://github.com/haproxy/haproxy/issues/2569 chacha20 is > disabled completely on LibreSSL. let's add a comment to not forget > enabling it (...) series applied, thanks Ilya! Willy

Re: [PATCH] FEATURE/MAJOR: Add upstream-proxy-tunnel feature

Hi Willy. On 2024-08-12 (Mo.) 16:49, Willy Tarreau wrote: Hi Alex, On Mon, Aug 12, 2024 at 11:46:37AM +0200, Aleksandar Lazic wrote: On Thu, Jun 13, 2024 at 03:00:59AM +0200, Aleksandar Lazic wrote: The final idea is something like this. ``` tcp-request content upstream-proxy-header Host %[r

Re: Tuning HTTP/2 window size

Hi Max, On Wed, Aug 14, 2024 at 06:21:39AM +, Moehl, Maximilian wrote: > Hi Willy, > > > > Is there a similar mechanism in HAProxy? So far I can only see the > > > static option for the initial window size which comes with the mentioned > > > drawbacks. > > > > There is nothing similar. One o

Re: [PATCH] DOC: fix incorrect english in lua.txt

Sending it again because it seems it never reached the mailing list for some reason!? On 13 Aug, Nicolas CARPi wrote: > Dear maintainers, > > Please find attached a patch for a few mistakes I found in doc/lua.txt > file. > > Best, > ~Nicolas >From f9cff910630851658a9f126caf1009e08dec Mon

Re: Tuning HTTP/2 window size

at > the same time over a same connection. Either they're uploading a large file > or downloading contents to be rendered. I agree, that seems to be the case for our scenarios. > That's something to think about. Thanks for re-heating this old topic! Thanks for taking the time to look into it! Regards Max

Re: Company to set up your product

You've reached open-source mailing list. please clarify what product do you mean, open source HAProxy ? if some of commercial product, maybe the best place would be Contact HAProxy Technologies вт, 13 авг. 2024 г. в 10:18, Christopher Doerr : > Hello, > > We

Re: Tuning HTTP/2 window size

ncrease the window when allocating new buffers. In our case, buffers were really not meant to be extensible on the rx side, but I suspect it might not be too hard to do. I'll also need to have a look at what Cloudflare did for NGINX, they might have updated that based on their observations and corner cases. That's something to think about. Thanks for re-heating this old topic! Willy

Re: minor correction to the configuration manual

Hi Nathan, On Tue, Aug 13, 2024 at 05:45:37PM +, Nathan Wehrman wrote: > The configuration manual currently lists "option tcplog" as valid for use in > a backend. > This is not correct. This patch simply fixes that one line. Thank you, you're right, now merged. Please check your git setup, I

Re: [PATCH] CI: keep logs for failed QIUC Interop jobs

ping :) this will allow to investigate the following failures: QUIC Interop LibreSSL · haproxy/haproxy@0982bfd · GitHub ср, 7 авг. 2024 г. в 13:03, Илья Шипицин : > patch attached. > > ср, 7 авг. 2024 г. в 12:34, Илья

Re: [PATCH] BUG/BUILD: deviceatlas: corrected path for *.cpp file compilation

No worries :) thanks for your concern. Cheers. On Mon, Aug 12, 2024 at 1:04 PM Miroslav Zagorac wrote: > On 12. 08. 2024. 13:50, David Carlier wrote: > > Hi Miroslav, > > > > Am I correct to assume the line you deleted relates to the dummy build > > version of the DA library ? > > > > The sole C

Re: [PATCH] FEATURE/MAJOR: Add upstream-proxy-tunnel feature

Hi Alex, On Mon, Aug 12, 2024 at 11:46:37AM +0200, Aleksandar Lazic wrote: > > On Thu, Jun 13, 2024 at 03:00:59AM +0200, Aleksandar Lazic wrote: > > > > The final idea is something like this. > > > > > > > > ``` > > > > tcp-request content upstream-proxy-header Host %[req.ssl_sni,lower] > > > > t

Re: [PATCH] BUG/BUILD: deviceatlas: corrected path for *.cpp file compilation

On 12. 08. 2024. 13:50, David Carlier wrote: > Hi Miroslav, > > Am I correct to assume the line you deleted relates to the dummy build > version of the DA library ? > > The sole C++ compilation unit is already taken care of above `(ifeq > (DEVICEATLAS_NOCACHE),)`. > > Regards. Hello David, I j

Re: [PATCH] BUG/BUILD: deviceatlas: corrected path for *.cpp file compilation

Hi Miroslav, Am I correct to assume the line you deleted relates to the dummy build version of the DA library ? The sole C++ compilation unit is already taken care of above `(ifeq (DEVICEATLAS_NOCACHE),)`. Regards. On Mon, Aug 12, 2024 at 11:35 AM Miroslav Zagorac wrote: > Hello all, > > This

Re: [PATCH] FEATURE/MAJOR: Add upstream-proxy-tunnel feature

Hi Willy. On 2024-08-12 (Mo.) 10:01, Willy Tarreau wrote: Hi Alex, I finally found time to have a look into this! Great :-) On Thu, Jun 13, 2024 at 03:00:59AM +0200, Aleksandar Lazic wrote: The final idea is something like this. ``` tcp-request content upstream-proxy-header Host %[req.ssl

Re: [PATCH] FEATURE/MAJOR: Add upstream-proxy-tunnel feature

Hi Alex, I finally found time to have a look into this! On Thu, Jun 13, 2024 at 03:00:59AM +0200, Aleksandar Lazic wrote: > > The final idea is something like this. > > > > ``` > > tcp-request content upstream-proxy-header Host %[req.ssl_sni,lower] > > tcp-request content upstream-proxy-header "

Re: Opinions desired on dropping support for duplicate names

Hi. On 2024-08-09 (Fr.) 17:24, Willy Tarreau wrote: Hi all, I'm continuing to find disgusting things in the code that are only here for historical reasons which, in my opinion, should no longer exist. [snipp] Now we're at an era where many configs are generated in ways that cannot even pro

Re: [RFC] Allow disabling abstract unix socket paths NUL-padding

Hi Tristan, I'm back on this topic (I had not forgotten it). On Sat, Mar 09, 2024 at 07:02:34PM +, Tristan wrote: > > > On 09/03/2024 18:09, Tristan wrote: > > Hi Willy, > > > > On 09/03/2024 16:51, Willy Tarreau wrote: > > > Hi Tristan, > > > > > > On Sat, Mar 09, 2024 at 04:20:21PM +000

Re: Opinions desired on dropping support for duplicate names

Hi Tristan, On Fri, Aug 09, 2024 at 03:51:24PM +, Tristan wrote: > Hi Willy, > > > On 9 Aug 2024, at 16:26, Willy Tarreau wrote: > > [...] > > I'd be interested in opinions on some of these options: > > - deprecate duplicate server names for 3.1, requiring a global option > >to support

Re: Opinions desired on dropping support for duplicate names

Hi Willy, > On 9 Aug 2024, at 16:26, Willy Tarreau wrote: > […] > I'd be interested in opinions on some of these options: > - deprecate duplicate server names for 3.1, requiring a global option >to support them and drop their support for 3.3 ? > - just drop the support of duplicate server

Re: [PATCH] FEATURE: Adding MPTCP with option to disable it and fall-back to TCP

Hi Matthieu, On Fri, Aug 09, 2024 at 12:52:04PM +0200, Matthieu Baerts wrote: > On 09/08/2024 11:32, Willy Tarreau wrote: > > On Mon, May 06, 2024 at 02:10:02PM +0200, Björn Jacke wrote: > >> Hi, > >> > >> I came up a while ago with a patchset for MPTCP support for HAProxy also, > >> see https://g

Re: [PATCH] FEATURE: Adding MPTCP with option to disable it and fall-back to TCP

Hi Willy, On 09/08/2024 11:32, Willy Tarreau wrote: > Hi Björn, > > I'm coming back to this: > > On Mon, May 06, 2024 at 02:10:02PM +0200, Björn Jacke wrote: >> Hi, >> >> I came up a while ago with a patchset for MPTCP support for HAProxy also, >> see https://github.com/haproxy/haproxy/issues/10

Re: [PATCH] FEATURE: Adding MPTCP with option to disable it and fall-back to TCP

Hi Björn, I'm coming back to this: On Mon, May 06, 2024 at 02:10:02PM +0200, Björn Jacke wrote: > Hi, > > I came up a while ago with a patchset for MPTCP support for HAProxy also, > see https://github.com/haproxy/haproxy/issues/1028 > > Back then I also discussed some ideas with Willy how to im

Re: [PATCH] FEATURE: Adding MPTCP with option to disable it and fall-back to TCP

Hi Matthieu, first, sorry for the long delay, but each time it's the same, the list of pending urgent things drags me away. I'm back on this. On Mon, Jun 03, 2024 at 05:33:31PM +0200, Matthieu Baerts wrote: > >>> and I'd really really prefer that we use the extended syntax for > >>> addresses tha

Re: [ANNOUNCE] haproxy-3.1-dev5

Hi Ilya, On Wed, Aug 07, 2024 at 08:30:46PM +0200, ??? wrote: > > HAProxy 3.1-dev5 was released on 2024/08/07. It added 88 new commits > > after version 3.1-dev4. > > > > There were quite a bunch of fixes this time, spread over various areas > > (h2, analysers, jwt, quic, 0-rtt, queues, t

Re: [ANNOUNCE] haproxy-3.1-dev5

ср, 7 авг. 2024 г. в 18:48, Willy Tarreau : > Hi, > > HAProxy 3.1-dev5 was released on 2024/08/07. It added 88 new commits > after version 3.1-dev4. > > There were quite a bunch of fixes this time, spread over various areas > (h2, analysers, jwt, quic, 0-rtt, queues, traces), though nothing exciti

Re: [PATCH] CI: keep logs for failed QIUC Interop jobs

patch attached. ср, 7 авг. 2024 г. в 12:34, Илья Шипицин : > please ignore, I'll send better patch > > ср, 7 авг. 2024 г. в 12:33, Ilia Shipitsin : > >> it might be useful to investigate logs of failed tests. to keep >> artifacts small the following actions are taken >> - only failed logs are kep

Re: [PATCH] CI: keep logs for failed QIUC Interop jobs

please ignore, I'll send better patch ср, 7 авг. 2024 г. в 12:33, Ilia Shipitsin : > it might be useful to investigate logs of failed tests. to keep > artifacts small the following actions are taken > - only failed logs are kept > - logs retention is 6 days > --- > .github/workflows/quic-interop

Re: [PR] Create SECURITY.md

On Tue, Aug 06, 2024 at 09:59:41PM +0200, Nicolas CARPi wrote: > Hello all, > > I wrote a blog post regarding the availability of this file for the > biggest 5000 websites. Have a look if you're interested: > > https://www.deltablot.com/posts/state-of-security-txt/ Thank you Nicolas! Willy

Re: [PR] Create SECURITY.md

Hello all, I wrote a blog post regarding the availability of this file for the biggest 5000 websites. Have a look if you're interested: https://www.deltablot.com/posts/state-of-security-txt/ Best, ~Nicolas

Re: [PATCH] src/fcgi-app.c: handle strdup failure

On Tue, Aug 06, 2024 at 08:35:21AM +0200, ??? wrote: > I'll provide better script. It is not actual patching, but detection (which > looks like a patching) Yes I know, I'm used to that as well. Our other scripts do that, they provide a patch and that's used to detect in the end. But that'

Re: [PATCH] src/fcgi-app.c: handle strdup failure

I'll provide better script. It is not actual patching, but detection (which looks like a patching) Thanks! On Tue, Aug 6, 2024, 08:25 Willy Tarreau wrote: > On Tue, Aug 06, 2024 at 05:16:11AM +0200, Willy Tarreau wrote: > > > diff --git a/src/fcgi-app.c b/src/fcgi-app.c > > > index b3a9b7c59..9

Re: [PATCH] src/fcgi-app.c: handle strdup failure

On Tue, Aug 06, 2024 at 05:16:11AM +0200, Willy Tarreau wrote: > > diff --git a/src/fcgi-app.c b/src/fcgi-app.c > > index b3a9b7c59..98077b959 100644 > > --- a/src/fcgi-app.c > > +++ b/src/fcgi-app.c > > @@ -606,6 +606,8 @@ static int proxy_parse_use_fcgi_app(char **args, int > > section, struct p

Re: [PATCH] src/fcgi-app.c: handle strdup failure

nd : > > > >> On Mon, Aug 05, 2024 at 08:01:39PM +0200, ??? wrote: > >> > Subject: Re: [PATCH] src/fcgi-app.c: handle strdup failure > >> > ??, 5 ???. 2024 ?. ? 19:56, William Lallemand : > >> > > >> > > On Mon, Aug 05, 2024

Re: [PATCH] src/fcgi-app.c: handle strdup failure

updated patch attached (I preferred that instead of sending with "git send-email") пн, 5 авг. 2024 г. в 20:10, Илья Шипицин : > > > пн, 5 авг. 2024 г. в 20:09, William Lallemand : > >> On Mon, Aug 05, 2024 at 08:01:39PM +0200, Илья Шипицин wrote: >> > Subjec

Re: [PATCH] src/fcgi-app.c: handle strdup failure

пн, 5 авг. 2024 г. в 20:09, William Lallemand : > On Mon, Aug 05, 2024 at 08:01:39PM +0200, Илья Шипицин wrote: > > Subject: Re: [PATCH] src/fcgi-app.c: handle strdup failure > > пн, 5 авг. 2024 г. в 19:56, William Lallemand : > > > > > On Mon, Aug 05, 2024 at 07

Re: [PATCH] src/fcgi-app.c: handle strdup failure

On Mon, Aug 05, 2024 at 08:01:39PM +0200, Илья Шипицин wrote: > Subject: Re: [PATCH] src/fcgi-app.c: handle strdup failure > пн, 5 авг. 2024 г. в 19:56, William Lallemand : > > > On Mon, Aug 05, 2024 at 07:17:48PM +0200, Ilia Shipitsin wrote: > > > Subject: [PATCH] src/f

Re: [PATCH] src/fcgi-app.c: handle strdup failure

пн, 5 авг. 2024 г. в 19:56, William Lallemand : > On Mon, Aug 05, 2024 at 07:17:48PM +0200, Ilia Shipitsin wrote: > > Subject: [PATCH] src/fcgi-app.c: handle strdup failure > > found by coccinelle > > Please add clearer commit messages in your patches, you tend to minimize > them, thanks ! :-) >

Re: [PATCH] src/fcgi-app.c: handle strdup failure

On Mon, Aug 05, 2024 at 07:17:48PM +0200, Ilia Shipitsin wrote: > Subject: [PATCH] src/fcgi-app.c: handle strdup failure > found by coccinelle Please add clearer commit messages in your patches, you tend to minimize them, thanks ! :-) > --- > src/fcgi-app.c | 5 - > 1 file changed, 4 insert

Re: [PR] Create SECURITY.md

On Sat, Aug 03, 2024 at 12:23:03PM +, PR Bot wrote: > Dear list! > > Author: Valen1393 > Number of patches: 1 > > This is an automated relay of the Github pull request: >Create SECURITY.md > > Patch title(s): >Create SECURITY.md > > Link: >https://github.com/haproxy/haproxy/pu

Re: [PR] Create SECURITY.md

Hi Nicolas, [ dropped security@, it's not too much spammed yet, I prefer to limit exposure ] On Sun, Aug 04, 2024 at 08:20:33PM +0200, Nicolas CARPi wrote: > Hello list, > > This PR made me think about the new security.txt standard - or at least > proposed standard: https://securitytxt.org/ >

Re: [PATCH] CI: harden NetBSD builds by ERR=1

On Sat, Aug 03, 2024 at 02:59:24PM +0200, Илья Шипицин wrote: > Subject: Re: [PATCH] CI: harden NetBSD builds by ERR=1 > ping :) > Thanks, merged. -- William Lallemand

Re: [PATCH] CI: add weekly QUIC Interop regression against AWS-LC

On Sat, Aug 03, 2024 at 03:43:36PM +0200, Ilia Shipitsin wrote: > Subject: [PATCH] CI: add weekly QUIC Interop regression against AWS-LC > currently only quic-go and picoquic clients are enabled. > Tests will be run weekly. Thanks, merged. -- William Lallemand

Re: [ANNOUNCE] haproxy-3.0.3

On Sun, Aug 04, 2024 at 09:39:25PM +0200, Vincent Bernat wrote: > > On 2024-07-22 21:59, Willy Tarreau wrote: > > > > > HAProxy 3.0.3 was released on 2024/07/11. It added 42 new commits > > > > after version 3.0.2. > > > > > > I am late releasing this version on haproxy.debian.net. I have issues

Re: [ANNOUNCE] haproxy-3.0.3

On 2024-07-22 21:59, Willy Tarreau wrote: HAProxy 3.0.3 was released on 2024/07/11. It added 42 new commits after version 3.0.2. I am late releasing this version on haproxy.debian.net. I have issues with compiling for ARM64. There is a known bug in recent version of QEMU segfaulting on ARM64

Re: [PR] Create SECURITY.md

Hello list, This PR made me think about the new security.txt standard - or at least proposed standard: https://securitytxt.org/ Basically, you serve a text file at .well-known/security.txt, and this should be the first place to look for a contact to send security reports to the dev team by sec

Re: [PATCH] CI: harden NetBSD builds by ERR=1

ping :) вс, 21 июл. 2024 г. в 13:52, Ilia Shipitsin : > --- > .github/workflows/netbsd.yml | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/.github/workflows/netbsd.yml b/.github/workflows/netbsd.yml > index 6514725e1..c6b431acc 100644 > --- a/.github/workflows/netbsd.yml

Re: Some HTTP connections not closing properly on Haproxy 2.8.10

Hi, I finally found some issues. Not sure it is exactly yours. But it is very similar. So I'm confident. I pushed 3 new fixes in 3.1-DEV. It may be good to check on the 3.0 if this fully fixes all your issues. And eventually, if possible, on 2.8 too, with the splicing enabled. In attachement

Re: Bug Report

Hello, On Thu, Aug 01, 2024 at 09:09:18PM +0500, Jenny Rose wrote: > Hi Team, > I hope you are well. > > I would like to share another vulnerability of your website > > Vulnerability 1: Non - secure requests are not automatically upgraded to > HTTPS | HSTS missing > > Description > > The appli

Re: Some HTTP connections not closing properly on Haproxy 2.8.10

Le 30/07/2024 à 17:23, Jens Wahnes a écrit : Thanks for the confirmation. On 3.0, I was unable to reproduce the issue. So I'm not surprised. On version 3.0.3 with splicing turned on, I actually did end up with a backend connection in state CLOSE_WAIT that is still around after some hours. But i

Re: Some HTTP connections not closing properly on Haproxy 2.8.10

Hi Christopher, Christopher Faulet wrote: Le 29/07/2024 à 16:30, Jens Wahnes a écrit : Christopher Faulet wrote: Le 29/07/2024 à 09:05, Christopher Faulet a écrit : Thanks, I will investigate. It is indeed most probably an issue with the splicing, as Willy said. I will try to find the bug

Re: Some HTTP connections not closing properly on Haproxy 2.8.10

Le 29/07/2024 à 16:30, Jens Wahnes a écrit : Christopher Faulet wrote: Le 29/07/2024 à 09:05, Christopher Faulet a écrit : Thanks, I will investigate. It is indeed most probably an issue with the splicing, as Willy said. I will try to find the bug on the 2.8 and figure out if upper versions ar

Re: Some HTTP connections not closing properly on Haproxy 2.8.10

Christopher Faulet wrote: Le 29/07/2024 à 09:05, Christopher Faulet a écrit : Thanks, I will investigate. It is indeed most probably an issue with the splicing, as Willy said. I will try to find the bug on the 2.8 and figure out if upper versions are affected too. I'm able to reproduce the

Re: Some HTTP connections not closing properly on Haproxy 2.8.10

Le 29/07/2024 à 09:05, Christopher Faulet a écrit : Thanks, I will investigate. It is indeed most probably an issue with the splicing, as Willy said. I will try to find the bug on the 2.8 and figure out if upper versions are affected too. I'm able to reproduce the issue by hacking the code, fo

Re: Some HTTP connections not closing properly on Haproxy 2.8.10

Le 26/07/2024 à 19:51, Jens Wahnes a écrit : Hi everyone, I'm trying to move from Haproxy 2.4 to 2.8 and encountered some trouble with 2.8 that did not occur on 2.4. Specifically, this seems to concern plain HTTP connections only, i.e. non-HTTPS traffic. I have not seen an example of this happen

Re: Some HTTP connections not closing properly on Haproxy 2.8.10

Hi Willy, thanks so much for looking into this. I certainly didn't expect an answer over the weekend and I really appreciate your taking time to look into this. Please find my comments below. Willy Tarreau wrote: On Fri, Jul 26, 2024 at 07:51:47PM +0200, Jens Wahnes wrote: Some of the backe

Re: Some HTTP connections not closing properly on Haproxy 2.8.10

Hi Jens, On Fri, Jul 26, 2024 at 07:51:47PM +0200, Jens Wahnes wrote: > Hi everyone, > > I'm trying to move from Haproxy 2.4 to 2.8 and encountered some trouble with > 2.8 that did not occur on 2.4. > Specifically, this seems to concern plain HTTP connections only, i.e. > non-HTTPS traffic. I hav

Re: [ANNOUNCE] haproxy-3.1-dev2

On 2024-07-26 (Fr.) 10:49, Willy Tarreau wrote: On Fri, Jul 26, 2024 at 10:40:46AM +0200, ??? wrote: next point: 0-RTT Sorry for the stupid questions but as I don't maintain any QUIC based apps I'm curious if this really makes any differences compared to "normal" requests. How oft

Re: [ANNOUNCE] haproxy-3.1-dev2

On Fri, Jul 26, 2024 at 10:40:46AM +0200, ??? wrote: > > > next point: 0-RTT > > > > Sorry for the stupid questions but as I don't maintain any QUIC based apps > > I'm > > curious if this really makes any differences compared to "normal" requests. > > > > How often is this really used in t

Re: [ANNOUNCE] haproxy-3.1-dev2

пт, 26 июл. 2024 г. в 09:55, Aleksandar Lazic : > Hi. > > On 2024-07-25 (Do.) 23:22, Илья Шипицин wrote: > > > > > > чт, 25 июл. 2024 г. в 22:00, Илья Шипицин > >: > > > > > > > > чт, 25 июл. 2024 г. в 14:27, William Lallemand > >:

Re: [ANNOUNCE] haproxy-3.1-dev2

Hi. On 2024-07-25 (Do.) 23:22, Илья Шипицин wrote: чт, 25 июл. 2024 г. в 22:00, Илья Шипицин >: чт, 25 июл. 2024 г. в 14:27, William Lallemand mailto:wlallem...@irq6.net>>: On Wed, Jul 03, 2024 at 11:51:21PM +0200, William Lallemand wrote:

Re: [ANNOUNCE] haproxy-3.1-dev2

пт, 26 июл. 2024 г. в 09:14, William Lallemand : > On Thu, Jul 25, 2024 at 11:22:25PM +0200, Илья Шипицин wrote: > > Subject: Re: [ANNOUNCE] haproxy-3.1-dev2 > > чт, 25 июл. 2024 г. в 22:00, Илья Шипицин : > > > > > > > > > > > чт, 25 июл. 2024 г.

Re: [ANNOUNCE] haproxy-3.1-dev2

On Thu, Jul 25, 2024 at 11:22:25PM +0200, Илья Шипицин wrote: > Subject: Re: [ANNOUNCE] haproxy-3.1-dev2 > чт, 25 июл. 2024 г. в 22:00, Илья Шипицин : > > > > > > > чт, 25 июл. 2024 г. в 14:27, William Lallemand : > > > >> On Wed, Jul 03, 2024 at

Re: [ANNOUNCE] haproxy-3.1-dev2

чт, 25 июл. 2024 г. в 22:00, Илья Шипицин : > > > чт, 25 июл. 2024 г. в 14:27, William Lallemand : > >> On Wed, Jul 03, 2024 at 11:51:21PM +0200, William Lallemand wrote: >> > > aws-lc implements chacha20_poly1305 in a different way than QuicTLS. >> > > and if that gap is eliminated, it will be a

Re: [ANNOUNCE] haproxy-3.1-dev2

чт, 25 июл. 2024 г. в 14:27, William Lallemand : > On Wed, Jul 03, 2024 at 11:51:21PM +0200, William Lallemand wrote: > > > aws-lc implements chacha20_poly1305 in a different way than QuicTLS. > > > and if that gap is eliminated, it will be a good point to declare > aws-lc as > > > a recommended Q

Re: [ANNOUNCE] haproxy-3.1-dev4

On Wed, 24 Jul 2024 at 23:19, William Lallemand wrote: > > On Wed, Jul 24, 2024 at 10:32:16PM +0200, Aleksandar Lazic wrote: > > Does this announcement have any impact to HAProxy? > > > > "Intent to End OCSP Service" > > https://letsencrypt.org/2024/07/23/replacing-ocsp-with-crls.html > > https://

Re: [ANNOUNCE] haproxy-3.1-dev2

On Wed, Jul 03, 2024 at 11:51:21PM +0200, William Lallemand wrote: > > aws-lc implements chacha20_poly1305 in a different way than QuicTLS. > > and if that gap is eliminated, it will be a good point to declare aws-lc as > > a recommended QUIC lib. > > > > if we compare aws-lc against openssl-1.1 (

Re: [ANNOUNCE] haproxy-3.1-dev4

ср, 24 июл. 2024 г. в 23:22, William Lallemand : > > On Wed, Jul 24, 2024 at 10:32:16PM +0200, Aleksandar Lazic wrote: > > Does this announcement have any impact to HAProxy? > > > > "Intent to End OCSP Service" > > https://letsencrypt.org/2024/07/23/replacing-ocsp-with-crls.html > > https://news.yc

Re: [ANNOUNCE] haproxy-3.1-dev4

On Wed, Jul 24, 2024 at 10:32:16PM +0200, Aleksandar Lazic wrote: > Does this announcement have any impact to HAProxy? > > "Intent to End OCSP Service" > https://letsencrypt.org/2024/07/23/replacing-ocsp-with-crls.html > https://news.ycombinator.com/item?id=41046956 > I read about this yesterday

Re: [ANNOUNCE] haproxy-3.1-dev4

ср, 24 июл. 2024 г. в 22:39, Willy Tarreau : > > Hi Alex, > > On Wed, Jul 24, 2024 at 10:32:16PM +0200, Aleksandar Lazic wrote: > > >- SPOE: the old applet-based architecture was replaced with the new > > > mux-based one which allows idle connections sharing between threads, > > > as

Re: [ANNOUNCE] haproxy-3.1-dev4

Hi Alex, On Wed, Jul 24, 2024 at 10:32:16PM +0200, Aleksandar Lazic wrote: > >- SPOE: the old applet-based architecture was replaced with the new > > mux-based one which allows idle connections sharing between threads, > > as well as queuing, load balancing, stickiness etc per reques

Re: [ANNOUNCE] haproxy-3.1-dev4

On 2024-07-24 (Mi.) 18:50, Willy Tarreau wrote: Hi, HAProxy 3.1-dev4 was released on 2024/07/24. It added 113 new commits after version 3.1-dev3. Some nice goodies came in this version: [snipp] - SPOE: the old applet-based architecture was replaced with the new mux-based one whic

Re: About the SPOE

On Wed, Jul 24, 2024 at 03:48:15PM +0200, Christopher Faulet wrote: > As announced, the SPOE was finally refactored. This new SPOE will be shipped > with the 3.1-dev4. It is a full rewrite of the engine, based on a dedicated > SPOP multiplexer. It means a "spop" proxy mode, used for SPOE backends,

Re: About the SPOE

Le 28/03/2024 à 18:14, Christopher Faulet a écrit : Thanks Lokesh, Abhijeet and Aleksandar for your feedback. This truly help us. Thanks too to Pierre and Mattia for their feedback on the request mirroring. Rest assured that we take this into account in our reflections. After some internal discu

Re: [ANNOUNCE] haproxy-3.0.3

Hi Vincent, On Mon, Jul 22, 2024 at 09:25:45PM +0200, Vincent Bernat wrote: > On 2024-07-11 16:51, Willy Tarreau wrote: > > Hi, > > > > HAProxy 3.0.3 was released on 2024/07/11. It added 42 new commits > > after version 3.0.2. > > I am late releasing this version on haproxy.debian.net. I have is

Re: [ANNOUNCE] haproxy-3.0.3

On 2024-07-11 16:51, Willy Tarreau wrote: Hi, HAProxy 3.0.3 was released on 2024/07/11. It added 42 new commits after version 3.0.2. I am late releasing this version on haproxy.debian.net. I have issues with compiling for ARM64. There is a known bug in recent version of QEMU segfaulting on A

Re: [ANNOUNCE] haproxy-3.1-dev3 (more infos on the story with fd-hard-limit and systemd)

On Wed, Jul 17, 2024 at 02:06:03PM +0200, Lukas Tribus wrote: > On Wed, 17 Jul 2024 at 11:25, Willy Tarreau wrote: > > > > At this point, do you (or anyone else) still have any objection against > > backporting the DEFAULT_MAXFD patch so as to preserve the current > > defaults for users, and/or do

Re: [ANNOUNCE] haproxy-3.1-dev3 (more infos on the story with fd-hard-limit and systemd)

On Wed, 17 Jul 2024 at 11:25, Willy Tarreau wrote: > > At this point, do you (or anyone else) still have any objection against > backporting the DEFAULT_MAXFD patch so as to preserve the current > defaults for users, and/or do you have any alternate proposal, or just > want to discuss other possib

Re: [ANNOUNCE] haproxy-3.1-dev3 (more infos on the story with fd-hard-limit and systemd)

Hi Lukas, On Tue, Jul 16, 2024 at 11:28:12PM +0200, Lukas Tribus wrote: > Hi Valentine, hi Willy, > > after spending some time testing I agree tuning maxconn/fd-limits is hard ... In fact we know that it's hard for experts, and it's even harder for new users. > With 8GB RAM we can still OOM wit

Re: [ANNOUNCE] haproxy-3.1-dev3 (more infos on the story with fd-hard-limit and systemd)

Hi Valentine, hi Willy, after spending some time testing I agree tuning maxconn/fd-limits is hard ... With 8GB RAM we can still OOM with 1M FDs / 500k maxconn (no TLS), but it appears to be around the sweetspot. It thought it would require more memory considering that we suggest 1GB of memory

Re: [PATCH] DOC: install: don't reference removed CPU arg

On Tue, Jul 16, 2024 at 05:47:50PM +, Lukas Tribus wrote: > Remove reference to the removed CPU= build argument in commit 018443b8a1 > ("BUILD: makefile: get rid of the CPU variable"). Oops, good catch, thank you Lukas! I've marked it for backporting to 3.0 as well. Now merged, thanks, Willy

Re: [ANNOUNCE] haproxy-3.1-dev3 (more infos on the story with fd-hard-limit and systemd)

Hi Lukas ! Hi All! Below are some links and comments just to provide more information on "fd-hard-limit" default value subject :). On 11/07/2024 12:17, Lukas Tribus wrote: Hi, I will get back to this for further research and discussion in about a week. In the meantime, do we agree that the

Re: [PATCH 1/1]: BUILD/MINOR: haproxy: fix SO_LINGER usage on macOs.

On Tue, Jul 16, 2024 at 05:27:10AM +0100, David CARLIER wrote: > Hi you are right I did not check properly, had a brain fog :) we can forget > it. Thanks. OK perfect, thanks :-) Willy

Re: [PATCH 1/1]: BUILD/MINOR: haproxy: fix SO_LINGER usage on macOs.

Hi you are right I did not check properly, had a brain fog :) we can forget it. Thanks. On Tue, 16 Jul 2024 at 03:59, Willy TARREAU wrote: > Hi David! > > On Mon, Jul 15, 2024 at 10:29:48PM +0100, David CARLIER wrote: > > Hi here a little patch proposal targeted for macOs. > > > > Cheers. > > >

Re: [PATCH 1/1]: BUILD/MINOR: haproxy: fix SO_LINGER usage on macOs.

Hi David! On Mon, Jul 15, 2024 at 10:29:48PM +0100, David CARLIER wrote: > Hi here a little patch proposal targeted for macOs. > > Cheers. > From df5741a0d391a7107157d0051ba81ef48d87b8f5 Mon Sep 17 00:00:00 2001 > From: David Carlier > Date: Mon, 15 Jul 2024 22:20:33 +0100 > Subject: [PATCH] BU

<    1   2   3   4   5   6   7   8   9   10   >