Re: [PATCH] CLEANUP: assorted typo fixes in the code and comments

On Thu, Feb 22, 2024 at 10:12:27AM +0100, Ilya Shipitsin wrote: > This is 39th iteration of typo fixes Now merged, thank you! I split it in two because the one on resolvers and stick-tables directly affects the code (it renames a function argument) and I want to make it easy to drop it in case

Re: [PATCH 0/1] CI: additional ASAN smoke tests

Hi Ilya, On Mon, Mar 04, 2024 at 10:41:12PM +0100, ??? wrote: > ping :) sorry, I wanted to double-check with others but forgot. Will do ASAP, thanks! Willy

Re: [PATCH 0/1] CI: additional ASAN smoke tests

ping :) сб, 17 февр. 2024 г. в 20:43, Ilya Shipitsin : > > > Ilya Shipitsin (1): > CI: run more smoke tests on config syntax to check memory related > issues > > .github/workflows/vtest.yml | 4 > 1 file changed, 4 insertions(+) > > -- > 2.43.2 > >

Re: RSA Conference Attendees Data List-2024

Hi, Would you be interested in acquiring RSA Conference Attendees Data List-2024? List Includes: Company Name, First Name, Last Name, Full Name, Contact Job Title, Verified Email Address, Website URL, Mailing address, Phone number, Industry and many more. Number of Contacts: 30,285

RE: RE: RSA Conference Attendees Emails List 2024

Hi, Hope you're doing well. Do you have any updates for me!? Please let me know if you require any further information. With Regards Naomi Stubbs From: Naomi Stubbs [mailto:www.bestdatabi...@gmail.com] Sent: Thursday, February 22, 2024 6:43 AM To: 'haproxy@formilux.org' Subject: RE

RE: RSA Conference Attendees Emails List 2024

Hi, Hope you're doing well. Would you be interested in acquiring RSA Conference Attendees Emails List 2024? List Includes:- Company/Org-Name, First Name, Last Name, Contact Job Title, Verified Email Address, Website URL, Mailing Address, Phone Number, Industry and many more. Number

Re: http/3 flow control equivalent

On Thu, Feb 22, 2024 at 12:47:04PM +1100, Miles Hampson wrote: > Hi, > I have noticed that transferring large files with http/2 to a backend > server through HAProxy 2.9 (and earlier) over a network link with a bit of > latency can be extremely slow unless the HTTP/2 Flow Control window size is >

Re: http/3 flow control equivalent

Hi. On 2024-02-22 (Do.) 02:47, Miles Hampson wrote: Hi, I have noticed that transferring large files with http/2 to a backend server through HAProxy 2.9 (and earlier) over a network link with a bit of latency can be extremely slow unless the HTTP/2 Flow Control window size is increased quite

Re: [PATCH] MINOR: lb-chash: Respect maxconn when selecting a server

Hi Willy, I wonder if I could accomplish what I'm looking to do by changing the behaviour of "maxqueue" (without making a breaking change, ideally). Currently, "maxqueue 0" is interpreted as "unlimited". However, the system I'm working with has long-running WebSocket connections, so a queued

Re: [PATCH] MEDIUM: lb-chash: Deterministic node hashes based on server address

Hi Willy, thanks for the thoughtful feedback. Here's a new patch that makes this configurable via a "hash-key" server argument, which defaults to "id" as you suggested. I'm struggling to test the last case you described. A quick description of my test setup: I have multiple instances of a simple

Re: [PATCH] MEDIUM: lb-chash: Deterministic node hashes based on server address

On Fri, Feb 16, 2024 at 05:03:56PM -0500, Anthony Deschamps wrote: > >From a031cf97da759eb2c2f9b6e191065ad503f821ed Mon Sep 17 00:00:00 2001 > From: Anthony Deschamps > Date: Fri, 16 Feb 2024 16:00:35 -0500 > Subject: [PATCH] MEDIUM: lb-chash: Deterministic node hashes based on server > address

Re: [PATCH] MINOR: lb-chash: Respect maxconn when selecting a server

Hi Anthony, On Tue, Feb 13, 2024 at 07:49:06PM -0500, Anthony Deschamps wrote: > >From 3fc983b719bd4d8af80037c36e7032e0af383557 Mon Sep 17 00:00:00 2001 > From: Anthony Deschamps > Date: Tue, 13 Feb 2024 18:11:56 -0500 > Subject: [PATCH] MINOR: lb-chash: Respect maxconn when selecting a server >

Re: [PATCH] DOC/MINOR: userlists: musl performance

On Mon, Feb 12, 2024 at 06:42:25PM +0100, Lukas Tribus wrote: > On Mon, 12 Feb 2024 at 18:10, Nicolas CARPi wrote: > > > > Dear Lukas, Willy, > > > > Please find another patch attached, addressing your comments. > > > > Willy: s/gcc/glibc/ > > > > Lukas: I shifted the focus on the rounds/cost

Re: Haproxy accross LDAPS

s, Willy *De :* Aleksandar Lazic *Envoyé :* jeudi 15 février 2024 15:20 *À :* TINK-LONG-KI Willy *Cc :* haproxy@formilux.org *Objet :* Re: Haproxy accross LDAPS Hi Willy. On 2024-02-15 (Do.) 09:07, TINK-LONG-KI Willy wrote: Hello All, I trying  to configure

Re: Haproxy accross LDAPS

Hi Willy. On 2024-02-15 (Do.) 09:07, TINK-LONG-KI Willy wrote: Hello All, I trying  to configure a backend on a HAPROXY (release 2.4.25) with LDAPS in order to authenticate user by the LDAPS. Any chance to use the latest 2.8 or 2.9? Below informations about my configuration : -Port use

Re: unsubscribe

Hi. Here can you find the right way to Unsubscribe from the list https://www.haproxy.org/#tact Regards Alex On 2024-02-12 (Mo.) 23:02, Nicolas Grilly wrote: *Nicolas Grilly* Managing Partner +33 6 03 00 25 34 Recrutez plus rapidement avec VocationCity.com

Re: [PATCH] DOC/MINOR: userlists: musl performance

On Mon, 12 Feb 2024 at 18:10, Nicolas CARPi wrote: > > Dear Lukas, Willy, > > Please find another patch attached, addressing your comments. > > Willy: s/gcc/glibc/ > > Lukas: I shifted the focus on the rounds/cost solution, while still > mentioning the musl issue, as this problem is clearly more

Re: [PATCH] DOC/MINOR: userlists: musl performance

Dear Lukas, Willy, Please find another patch attached, addressing your comments. Willy: s/gcc/glibc/ Lukas: I shifted the focus on the rounds/cost solution, while still mentioning the musl issue, as this problem is clearly more visible on Alpine Linux, as the github issues show. Cheers,

Re: [PATCH] DOC/MINOR: userlists: musl performance

On Mon, 12 Feb 2024 at 14:13, Nicolas CARPi wrote: > > Hello everyone, > > Please find attached my very first patch to the documentation. Hope I > did everything good! :) > > Based on a comment from @bugre: > https://github.com/haproxy/haproxy/issues/2251#issuecomment-1716594046 > > (and also

Re: [PATCH] DOC/MINOR: userlists: musl performance

Hi Nicolas, On Mon, Feb 12, 2024 at 02:13:18PM +0100, Nicolas CARPi wrote: > Hello everyone, > > Please find attached my very first patch to the documentation. Hope I > did everything good! :) Thank you! I have one comment below: > + Furthermore, there is a significant performance penalty

Re: WolfSSL builds for use with HAProxy

On Fri, Feb 09, 2024 at 11:00:24PM +, Tristan wrote: > Hi Ilya, > > On 09/02/2024 20:31, Илья Шипицин wrote: > > I run QUIC Interop from time to time, WolfSSL shows the best > > compatibility compared to LibreSSL and aws-lc. > > it really looks like a winner today > > And in comparison to

Re: WolfSSL builds for use with HAProxy

On Thu, Feb 08, 2024 at 02:46:46PM +, Tristan wrote: > Hi all, > Hello, > With the ever-increasing threat of one day needing to give up on OpenSSL > 1.1.1 (whenever the next bad CVE is found on QuicTLS 1.1.1w, essentially) I > was looking at alternatives a bit closer. > > Based on the

Re: WolfSSL builds for use with HAProxy

сб, 10 февр. 2024 г. в 00:00, Tristan : > Hi Ilya, > > On 09/02/2024 20:31, Илья Шипицин wrote: > > I run QUIC Interop from time to time, WolfSSL shows the best > > compatibility compared to LibreSSL and aws-lc. > > it really looks like a winner today > > And in comparison to current QuicTLS? >

Re: [PATCH] CI: Update to actions/cache@v4

Hi Tim! On Thu, Feb 08, 2024 at 07:55:23PM +0100, Tim Duesterhus wrote: > No functional change, but this upgrade is required, due to the v3 runtime > being > deprecated: > > > Node.js 16 actions are deprecated. Please update the following actions to > > use > > Node.js 20: actions/cache@v3.

Re: WolfSSL builds for use with HAProxy

Hi Ilya, On 09/02/2024 20:31, Илья Шипицин wrote: I run QUIC Interop from time to time, WolfSSL shows the best compatibility compared to LibreSSL and aws-lc. it really looks like a winner today And in comparison to current QuicTLS? I'm afraid it practice it works in a different way. First,

Re: WolfSSL builds for use with HAProxy

чт, 8 февр. 2024 г. в 15:49, Tristan : > Hi all, > > With the ever-increasing threat of one day needing to give up on OpenSSL > 1.1.1 (whenever the next bad CVE is found on QuicTLS 1.1.1w, > essentially) I was looking at alternatives a bit closer. > > Based on the wiki, >

Re: Managing haproxy configs at scale

Hi Zach, (Replying on the ML since your reply was directly to me only) On 08/02/2024 21:10, Zach Pearson wrote: Thanks for the reply, Tristan, and sorry for the late reply! To add a little more context for our haproxy setup, we currently deploy haproxy along with a sidecar control-plane that

Re: pcre vs pcre2, which one to use?

On Wed, Feb 07, 2024 at 07:07:13PM -0800, Abhijeet Rastogi wrote: > Hi Willy, > > Thanks for the quick clarification. I've sent a patch. > > I also changed the "Quick build & install" section in the INSTALL doc to > use USE_PCRE2, so folks don't accidently use the older version. I hope that >

Re: pcre vs pcre2, which one to use?

Hi Willy, Thanks for the quick clarification. I've sent a patch. I also changed the "Quick build & install" section in the INSTALL doc to use USE_PCRE2, so folks don't accidently use the older version. I hope that was an intended change. On Wed, Feb 7, 2024 at 2:08 PM Willy Tarreau wrote: >

Re: pcre vs pcre2, which one to use?

Hi Abhijeet, On Wed, Feb 07, 2024 at 01:19:27PM -0800, Abhijeet Rastogi wrote: > Hi HAproxy community, > > I see that Makefile > suggests that > pcre1 is a recommended version to use, is that still true or a comment that > got out of

Re: [PATCH] DOC: install: clarify WolfSSL chroot requirements

On Fri, Feb 02, 2024 at 05:33:08PM +, Lukas Tribus wrote: > Subject: [PATCH] DOC: install: clarify WolfSSL chroot requirements > --- > INSTALL | 12 > 1 file changed, 12 insertions(+) > > diff --git a/INSTALL b/INSTALL > index 18eb67f311..8ebf8d298c 100644 > --- a/INSTALL > +++

Re: [PATCH 0/2] CI cleanup and improvement

On Fri, Feb 02, 2024 at 08:33:14PM +0100, Ilya Shipitsin wrote: > Subject: [PATCH 0/2] CI cleanup and improvement > remove redundant function, improve openssl download helper > > Ilya Shipitsin (2): > CI: cleanup: abandon asan matrix.py helper > BUILD: SSL: add yet another OpenSSL download

Re: ACL and operator

On Sat, Feb 03, 2024 at 01:18:30PM +, Tristan wrote: > > > > On 3 Feb 2024, at 15:18, Willy Tarreau wrote: > > > > Quite honestly, we've though about it several times but you can't enforce > > such a change on 20 years of configs everywhere. > > That is why I directly mentioned it being

Re: ACL and operator

> On 3 Feb 2024, at 15:18, Willy Tarreau wrote: > > Quite honestly, we've though about it several times but you can't enforce > such a change on 20 years of configs everywhere. That is why I directly mentioned it being some form of opt-in behavior, because indeed we can’t expect everyone to

Re: ACL and operator

On Sat, Feb 03, 2024 at 10:31:02AM +, Tristan wrote: > Hi Willy, > > > On 3 Feb 2024, at 12:48, Willy Tarreau wrote: > > > in fact we could check for > >> the presence of "and" or "or" on a line, or some other suspicious > >> constructs > > Another approach might be to optionally enforce

Re: ACL and operator

Hi Willy, > On 3 Feb 2024, at 12:48, Willy Tarreau wrote: > in fact we could check for >> the presence of "and" or "or" on a line, or some other suspicious >> constructs Another approach might be to optionally enforce quotes around strings. While it’d be a breaking change and sounds a bit

Re: ACL and operator

On Sat, Feb 03, 2024 at 09:10:42AM +0100, Willy Tarreau wrote: > On Fri, Feb 02, 2024 at 06:43:12PM +, Lukas Tribus wrote: > > On Fri, 2 Feb 2024 at 18:42, John Lauro wrote: > > > > > > Seems like a lint style checker that doesn't require AI. > > > For example, it could recognize that the /

Re: ACL and operator

On Fri, Feb 02, 2024 at 06:43:12PM +, Lukas Tribus wrote: > On Fri, 2 Feb 2024 at 18:42, John Lauro wrote: > > > > Seems like a lint style checker that doesn't require AI. > > For example, it could recognize that the / in /api isn't valid for > > req.hdr(host) > > [...] > > The _ in path_beg

Re: ACL and operator

On Fri, 2 Feb 2024 at 18:42, John Lauro wrote: > > Seems like a lint style checker that doesn't require AI. > For example, it could recognize that the / in /api isn't valid for > req.hdr(host) > [...] > The _ in path_beg is also questionable. You can have _ in dns names, > but are not valid in

Re: [PATCH] DOC: install: enable WOLFSSL_GETRANDOM

On 2024-02-02 16:38, Lukas Tribus wrote: WolfSSL support in HAProxy is experimental to the point that not only does it require compiling library and application from source, it also requires tinkering with LD paths to be able to even start the binary, so it's not like the INSTALL instructions

Re: [PATCH] DOC: install: enable WOLFSSL_GETRANDOM

On Fri, 2 Feb 2024 at 08:43, Willy Tarreau wrote: > > Hi Lukas! > > On Thu, Feb 01, 2024 at 02:52:10PM +, Lukas Tribus wrote: > > On Thu, 1 Feb 2024 at 12:08, William Lallemand > > wrote: > > > > > > That's interesting, however I'm surprised the init does not work before > > > the chroot,

Re: ACL and operator

On Fri, 2 Feb 2024 at 15:09, Tom Braarup wrote: > > Hi, > > The config validator does not seems to catch this error in syntax and Haproxy > ignores the second part of the expression: > > use_backend api.example.com if { req.hdr(host) -i example.com and path_beg > /api } This is correct syntax

RE: Formilux - Bio-IT Conference & Expo 2024 engage leads

Hi There, I see you're too busy to reply Could you please just hit me back "Interested or Not interested" So that I can send you "Free Samples and Counts" Thanks Amelia Jones - Trade show coordinator If you don't want to receive further emails revert with Take Out in the subject From:

Re: [PATCH] DOC: install: enable WOLFSSL_GETRANDOM

Hi Lukas! On Thu, Feb 01, 2024 at 02:52:10PM +, Lukas Tribus wrote: > On Thu, 1 Feb 2024 at 12:08, William Lallemand wrote: > > > > That's interesting, however I'm surprised the init does not work before the > > chroot, > > we are doing a RAND_bytes() with OpenSSL before the chroot to

Re: [PATCH] DOC: install: enable WOLFSSL_GETRANDOM

Hello William, On Thu, 1 Feb 2024 at 17:52, William Lallemand wrote: > > I consider getrandom() a modern and simple solution to all those problems. > > Unfortunately this is still a fallback solution if getrandom() is not > accessible or if the support is not built, as this is a fallback in >

Re: [PATCH] DOC: install: enable WOLFSSL_GETRANDOM

On 2024-02-01 15:52, Lukas Tribus wrote: On Thu, 1 Feb 2024 at 12:08, William Lallemand wrote: > > That's interesting, however I'm surprised the init does not work before the chroot, > we are doing a RAND_bytes() with OpenSSL before the chroot to achieve this. This approach can actually hide

Re: [PATCH] DOC: install: enable WOLFSSL_GETRANDOM

On Thu, 1 Feb 2024 at 12:08, William Lallemand wrote: > > That's interesting, however I'm surprised the init does not work before the > chroot, > we are doing a RAND_bytes() with OpenSSL before the chroot to achieve this. This approach can actually hide chroot issues leading to nasty

Re: Optimizing HAProxy CPU usage for SSL

Hi Willy, Thanks for your response, I learned a lot from reading it. > So that would give roughly 4000 SSL req/sec max over all cores, or only > 166 per core, that sounds quite low! > > Normally on a modern x86 CPU core, you should expect roughly 500 RSA2048/s > per core and per GHz (or keep in

Re: [PATCH] DOC: install: enable WOLFSSL_GETRANDOM

On 2024-01-30 20:45, Lukas Tribus wrote: Suggest enabling getrandom() syscall in wolfssl to avoid chroot problems when using wolfssl. --- Also see: https://discourse.haproxy.org/t/haproxy-no-responses-when-built-with-wolfssl-while-working-with-openssl/9320/15 --- INSTALL | 3 ++- 1 file

Re: Optimizing HAProxy CPU usage for SSL

Hi Miles, On Thu, Feb 01, 2024 at 05:09:20PM +1100, Miles Hampson wrote: > Hi, > > We recently hit an issue where we observed the > haproxy_frontend_current_sessions reported by the prometheus endpoint > plateau at 4095 and some requests start dropping. Increasing the global and > listen maxconn

Re: [RFC PATCH] DOC: httpclient: add dedicated httpclient section

Hello Lukas, On 2024-01-30 22:17, Lukas Tribus wrote: Move httpclient keywords into its own section and explain adding an introductory paragraph. Also see Github issue #2409 Should be backported to 2.6 ; but note that: 2.7 does not have httpclient.resolvers.disabled 2.6 does not have

Re: [PATCH] CLEANUP: log: deinitialization of the log buffer in one function

Hi Miroslav, On Tue, Jan 30, 2024 at 03:42:20AM +0100, Miroslav Zagorac wrote: > Hello all, > > In several places in the source, there was the same block of code that was > used to deinitialize the log buffer. There were even two functions that > did this, but they were called only from the

Re: [PATCH] DOC: configuration: clarify http-request wait-for-body

Hi Thayne, On Sun, Jan 28, 2024 at 10:07:32PM -0700, Thayne McCombs wrote: > Make it more explicit what happens in the various scenarios that cause > HAProxy to stop waiting when "http-request wait-for-body" is used. > > Also fix a couple of grammatical errors. > > Fixes: #2410 > Signed-Off-By:

Re: [PATCH 0/3] fix speling remnants, enable spel chek on push

On Fri, Jan 26, 2024 at 09:22:58PM +0100, ??? wrote: > ??, 26 ???. 2024 ?. ? 20:01, Willy Tarreau : > > > On Fri, Jan 26, 2024 at 05:30:31PM +0100, Willy Tarreau wrote: > > > On Wed, Jan 24, 2024 at 02:26:13PM +0100, Ilya Shipitsin wrote: > > > > it is very fast check, should not affect

Re: [PATCH 0/3] fix speling remnants, enable spel chek on push

пт, 26 янв. 2024 г. в 20:01, Willy Tarreau : > On Fri, Jan 26, 2024 at 05:30:31PM +0100, Willy Tarreau wrote: > > On Wed, Jan 24, 2024 at 02:26:13PM +0100, Ilya Shipitsin wrote: > > > it is very fast check, should not affect developer velocity much > > > > OK now pushed, thank you Ilya! > > Ilya,

Re: [PATCH 0/3] fix speling remnants, enable spel chek on push

On Fri, Jan 26, 2024 at 05:30:31PM +0100, Willy Tarreau wrote: > On Wed, Jan 24, 2024 at 02:26:13PM +0100, Ilya Shipitsin wrote: > > it is very fast check, should not affect developer velocity much > > OK now pushed, thank you Ilya! Ilya, I reverted the last one (automatic check on push) for

Re: PATCH 3/3: BUILD/MEDIUM: deviceatlas: addon code update

On Fri, Jan 26, 2024 at 06:35:09PM +, David Carlier wrote: > > > > It broke the CI on the "all features" build: > > > > > > https://github.com/haproxy/haproxy/actions/runs/7671640626/job/20910459829 > > > > /usr/bin/ld: cannot find -lcurl: No such file or directory > > /usr/bin/ld: cannot find

Re: PATCH 3/3: BUILD/MEDIUM: deviceatlas: addon code update

> > It broke the CI on the "all features" build: > > > https://github.com/haproxy/haproxy/actions/runs/7671640626/job/20910459829 > > /usr/bin/ld: cannot find -lcurl: No such file or directory > /usr/bin/ld: cannot find -lzip: No such file or directory > > I'm surprised because CURL_LDFLAGS and

Re: PATCH 3/3: BUILD/MEDIUM: deviceatlas: addon code update

On Fri, Jan 26, 2024 at 06:57:57PM +0100, Willy Tarreau wrote: > On Fri, Jan 26, 2024 at 05:38:20PM +, David Carlier wrote: > > I m good with your version. Thanks ! > > Great, now merged, thanks! > Willy It broke the CI on the "all features" build:

Re: PATCH 3/3: BUILD/MEDIUM: deviceatlas: addon code update

On Fri, Jan 26, 2024 at 05:38:20PM +, David Carlier wrote: > I m good with your version. Thanks ! Great, now merged, thanks! Willy

Re: PATCH 3/3: BUILD/MEDIUM: deviceatlas: addon code update

I m good with your version. Thanks ! On Fri, Jan 26, 2024 at 5:35 PM Willy Tarreau wrote: > On Fri, Jan 26, 2024 at 04:41:36PM +, David Carlier wrote: > > Hi, > > > > Please find the revised patch. > > OK thanks, it looks good and addresses the build issue. > > I noticed that when building

Re: PATCH 3/3: BUILD/MEDIUM: deviceatlas: addon code update

On Fri, Jan 26, 2024 at 04:41:36PM +, David Carlier wrote: > Hi, > > Please find the revised patch. OK thanks, it looks good and addresses the build issue. I noticed that when building with the dummy lib, we continue to link with -lstdc++ even if it's not used (unless DEVICEATLAS_NOCACHE=1)

Re: PATCH 3/3: BUILD/MEDIUM: deviceatlas: addon code update

Hi, Please find the revised patch. Regards. On Fri, Jan 26, 2024 at 4:28 PM Willy Tarreau wrote: > Hi David, > > On Thu, Jan 25, 2024 at 09:26:24AM +, David Carlier wrote: > > Finally the last piece related to the da's dummy update and da.c changes. > > Thanks. I'm getting the following

Re: [PATCH 0/3] fix speling remnants, enable spel chek on push

On Wed, Jan 24, 2024 at 02:26:13PM +0100, Ilya Shipitsin wrote: > it is very fast check, should not affect developer velocity much OK now pushed, thank you Ilya! Willy

Re: PATCH 3/3: BUILD/MEDIUM: deviceatlas: addon code update

Hi David, On Thu, Jan 25, 2024 at 09:26:24AM +, David Carlier wrote: > Finally the last piece related to the da's dummy update and da.c changes. Thanks. I'm getting the following build error: addons/deviceatlas/da.c: In function 'da_haproxy_checkinst': addons/deviceatlas/da.c:284:25:

Re: USE_QUIC=1 support for awslc

On 1/24/24 05:58, Yaacov Akiba Slama wrote: > So right now, the only thing missing in aws_lc in order to fully support > quic is the implementation of EVP_chacha20() ? This is one of the *identified* things which are missing in addition to TLS_AES_128_CCM_SHA256 which cannot be enabled. This does

Re: USE_QUIC=1 support for awslc

So right now, the only thing missing in aws_lc in order to fully support quic is the implementation of EVP_chacha20() ? Thanks a lot for your work, --yas On 23/01/2024 17:18, Frederic Lecaille wrote: FYI, I have just pushed 4 patches to master to make haproxy support 0-RTT when built against

Re: Managing haproxy configs at scale

On 23/01/2024 22:44, Zach Pearson wrote: Hello, We are using haproxy in a few different environments/functions and the configurations are getting complicated to manage. We are already using Jinja2 to generate environment specific configs but was wondering if anyone has suggestions on tools

Re: USE_QUIC=1 support for awslc

On 1/15/24 17:16, Yaacov Akiba Slama wrote: > On 04/10/2023 18:38, William Lallemand wrote: >> Hello, >> >> I fixed the build for USE_QUIC=1 and AWSLC which is limited like Ilya >> mentionned. >> >> For now: >> >>     - 0RTT was disabled. >>     - TLS1_3_CK_CHACHA20_POLY1305_SHA256,

Re: HAProxy Technologies NERC CIP 13 Vendor Questionnaire

On Tue, Jan 23, 2024 at 12:11:56PM +0100, ??? wrote: > how can HAProxy be related, for example, to "NERC requires CORE to revoke > access within 24 hours when remote or onsite > access is no longer needed by your personnel to CORE systems or > facilities." ? Ilya, please avoid responding

Re: HAProxy Technologies NERC CIP 13 Vendor Questionnaire

how can HAProxy be related, for example, to "NERC requires CORE to revoke access within 24 hours when remote or onsite access is no longer needed by your personnel to CORE systems or facilities." ? вт, 23 янв. 2024 г. в 00:58, Robert Dillabough : > Hi Support, > > For NERC compliance, CORE

Re: [PATCH] MEDIUM: sample: Modify fetchers for req.hdrs and res.hdrs to selectively include / exclude headers

before getting back to you. Thanks, Ruei-Bang From: Willy Tarreau Sent: Friday, January 19, 2024 6:28 AM To: Ruei-Bang Chen Cc: haproxy@formilux.org Subject: Re: [PATCH] MEDIUM: sample: Modify fetchers for req.hdrs and res.hdrs to selectively include / exclude

Re: [PATCH] MEDIUM: sample: Modify fetchers for req.hdrs and res.hdrs to selectively include / exclude headers

of a hiccup on the send side, so thanks for resending! Some comments below. > > From: Ruei-Bang Chen > Sent: Tuesday, December 12, 2023 5:32 PM > To: Willy Tarreau > Cc: haproxy@formilux.org > Subject: Re: [PATCH] MEDIUM: sample: Modify fetchers f

Re: Question on stats socket values

sts that encountered an error trying to connect to a backend server. The backend stat is the sum of the stat for all servers of that backend, plus any connection errors not associated with a particular server (such as the backend having no active servers). You can use that work

Re: Casino/Gambling Homepage Offer

Hello! I hope you are doing well and enjoy checking my previous email. Have you changed, Please any update me. waiting for your positive response. Thanks. On Tue, 13 Jun 2023 at 12:27, Mailtrack Notification < notificat...@mailtrack.io> wrote: >  Hot conversation: haproxy@formilux.org opened

Re: USE_QUIC=1 support for awslc

On 1/17/24 00:53, Hopkins, Andrew wrote: > AWS-LC recently plumbed support for ChaChaPoly and AES CCM through the > existing EVP_CIPHER API that HAProxy uses in > https://github.com/aws/aws-lc/pull/1311 and > https://github.com/aws/aws-lc/pull/1373. Do you need support for just the > cipher

Re: [PATCH] fix runtime 'FATAL ERROR: invalid code detected -- cannot go further' when building with Buildroot

Hello Aleksandr, On Tue, Jan 16, 2024 at 09:28:57PM +0200, Aleksandr Makarov wrote: > In buildroot, forcing HAPROXY_CFLAGS on the haproxy build command line > overrides CFLAGS > which were internally set by the package Makefile. > > In such a way, a bunch of flags that were deduced by the

Re: USE_QUIC=1 support for awslc

AWS-LC recently plumbed support for ChaChaPoly and AES CCM through the existing EVP_CIPHER API that HAProxy uses in https://github.com/aws/aws-lc/pull/1311 and https://github.com/aws/aws-lc/pull/1373. Do you need support for just the cipher EVP_chacha20? On 1/16/24, 5:30 AM, "Frederic

Re:

Dear Chic Closet, Hello, and thank you for reaching out to us regarding your need for a proxy. We appreciate your interest and are eager to assist you, but to provide you with the best possible solution, we need a bit more information about your specific requirements and the context of your

Re: USE_QUIC=1 support for awslc

On 1/16/24 14:25, Frederic Lecaille wrote: > On 1/15/24 17:16, Yaacov Akiba Slama wrote: >> On 04/10/2023 18:38, William Lallemand wrote: >>> Hello, >>> >>> I fixed the build for USE_QUIC=1 and AWSLC which is limited like Ilya >>> mentionned. >>> >>> For now: >>> >>>     - 0RTT was disabled. >>>   

Re: USE_QUIC=1 support for awslc

On 1/15/24 17:16, Yaacov Akiba Slama wrote: > On 04/10/2023 18:38, William Lallemand wrote: >> Hello, >> >> I fixed the build for USE_QUIC=1 and AWSLC which is limited like Ilya >> mentionned. >> >> For now: >> >>     - 0RTT was disabled. >>     - TLS1_3_CK_CHACHA20_POLY1305_SHA256,

Re: USE_QUIC=1 support for awslc

On 1/15/24 17:16, Yaacov Akiba Slama wrote: > On 04/10/2023 18:38, William Lallemand wrote: >> Hello, >> >> I fixed the build for USE_QUIC=1 and AWSLC which is limited like Ilya >> mentionned. >> >> For now: >> >>     - 0RTT was disabled. >>     - TLS1_3_CK_CHACHA20_POLY1305_SHA256,

Re: USE_QUIC=1 support for awslc

On 04/10/2023 18:38, William Lallemand wrote: Hello, I fixed the build for USE_QUIC=1 and AWSLC which is limited like Ilya mentionned. For now: - 0RTT was disabled. - TLS1_3_CK_CHACHA20_POLY1305_SHA256, TLS1_3_CK_AES_128_CCM_SHA256 were disabled

Re: [PATCH 0/3] spell check improvements

On Thu, Jan 11, 2024 at 08:49:08PM +0100, Ilya Shipitsin wrote: > few words are added to whitelists, few typos fixed Applied, thank you Ilya! Willy

Re: [ANNOUNCE] haproxy-2.9.2

Le 11/01/2024 à 16:14, Christopher Faulet a écrit : Hi, HAProxy 2.9.2 was released on 2024/01/11. It added 37 new commits after version 2.9.1. A major issue about the zero-copy forwarding in TCP mode was fixed in this release. A regression was introduced to the 2.9.1, blocking connection

Re: [PATCH] DOC: configuration: corrected description of keyword tune.ssl.ocsp-update.mindelay

Hi Miroslav, On Tue, Jan 09, 2024 at 09:14:24PM +0100, Miroslav Zagorac wrote: > Hello all, > > I'm not sure, but it seems to me that in the doc/configuration.txt > documentation, the paragraph related to the keyword > tune.ssl.ssl-ctx-cache-size was also copied for the description of > the

Re: Which fetcher to use for detecting a connection refused event?

Hi, On Tue, Jan 09, 2024 at 04:52:49PM -0500, J B wrote: > Hi folks. Just following up here. Still wondering about the prior request. > After some more research, it seems that "txn.sess_term_state" is only > available in HAProxy 2.9. Might there be a fetcher in 2.8 that can achieve > something

Re: Which fetcher to use for detecting a connection refused event?

Hi folks. Just following up here. Still wondering about the prior request. After some more research, it seems that "txn.sess_term_state" is only available in HAProxy 2.9. Might there be a fetcher in 2.8 that can achieve something similar? Thanks for your time. -Jesse On Wed, Jan 3, 2024 at 5:14 

Re: [PATCH] MEDIUM: sample: Modify fetchers for req.hdrs and res.hdrs to selectively include / exclude headers

-Bang From: Ruei-Bang Chen Sent: Tuesday, December 12, 2023 5:32 PM To: Willy Tarreau Cc: haproxy@formilux.org Subject: Re: [PATCH] MEDIUM: sample: Modify fetchers for req.hdrs and res.hdrs to selectively include / exclude headers Hi Willy, Sorry for the late

RE: [PATCH 0/1] Update ssl_fc_curve/ssl_bc_curve sample fetch

...@haproxy.com Subject: [EXTERNAL] Re: [PATCH 0/1] Update ssl_fc_curve/ssl_bc_curve sample fetch On 2024-01-08 21:01, Mariam John wrote: > > Thank you Willy for the update. Appreciate it. Please take your time. > I totally understand. Just wanted to make sure it wasn’t lost or > forgotten abou

Re: [PATCH 0/1] Update ssl_fc_curve/ssl_bc_curve sample fetch

On 2024-01-08 21:01, Mariam John wrote: Thank you Willy for the update. Appreciate it. Please take your time. I totally understand. Just wanted to make sure it wasn’t lost or forgotten about. Thank you once again. Regards, Mariam. Hello Mariam, Thank you for your contribution, I merged

Re: [PATCH] MINOR: ot: logsrv struct becomes logger

Hi Miroslav, On Mon, Jan 08, 2024 at 01:12:25PM +0100, Miroslav Zagorac wrote: > Hello all, > > after the patch 18da35c "MEDIUM: tree-wide: logsrv struct becomes logger", the > OpenTracing filter can no longer be compiled in debug mode. This patch fixes > it. > > This patch should be

Re: [PATCH 0/1] Update ssl_fc_curve/ssl_bc_curve sample fetch

On Mon, Jan 08, 2024 at 08:01:07PM +, Mariam John wrote: > Thank you Willy for the update. Appreciate it. Please take your time. I > totally understand. Just wanted to make sure it wasn't lost or forgotten > about. I knew you would naturally start to worry about it, I even mentioned it in the

RE: [PATCH 0/1] Update ssl_fc_curve/ssl_bc_curve sample fetch

, haproxy@formilux.org , eb...@haproxy.com , wlallem...@haproxy.com Subject: [EXTERNAL] Re: [PATCH 0/1] Update ssl_fc_curve/ssl_bc_curve sample fetch Hi Mariam, On Mon, Jan 08, 2024 at 02:40:22PM +, Mariam John wrote: > Happy new year!! Just wanted to see if this patch could move forward. I h

Re: [PATCH 0/1] Update ssl_fc_curve/ssl_bc_curve sample fetch

Hi Mariam, On Mon, Jan 08, 2024 at 02:40:22PM +, Mariam John wrote: > Happy new year!! Just wanted to see if this patch could move forward. I have > made the changes recommended by William. Yeah, we spoke about it this morning with William, he's still unpiling his mailbox :-) Rest assured

Re: [PATCH 0/1] Update ssl_fc_curve/ssl_bc_curve sample fetch

Happy new year!! Just wanted to see if this patch could move forward. I have made the changes recommended by William. Thank you for your time. Regards, Mariam. From: Mariam John Date: Friday, December 29, 2023 at 11:20 AM To: haproxy@formilux.org Cc: eb...@haproxy.com ,

Re: [ANNOUNCE] haproxy-3.0-dev1

On Sun, Jan 07, 2024 at 01:59:20PM +0100, Tim Düsterhus wrote: > Willy, > > On 1/6/24 15:08, Willy Tarreau wrote: > > HAProxy 3.0-dev1 was released on 2024/01/06. It added 136 new commits > > after version 3.0-dev0. I figured we're already one month after 2.9 was > > I just noticed that the

Re: [ANNOUNCE] haproxy-3.0-dev1

Willy, On 1/6/24 15:08, Willy Tarreau wrote: HAProxy 3.0-dev1 was released on 2024/01/06. It added 136 new commits after version 3.0-dev0. I figured we're already one month after 2.9 was I just noticed that the release date and EOL columns in haproxy.org are broken for 2.9 (missing exact

Re: [ANNOUNCE] haproxy-3.0-dev1

Hi Tim, On Sun, Jan 07, 2024 at 01:01:34PM +0100, Tim Düsterhus wrote: > Willy, > > On 1/6/24 15:08, Willy Tarreau wrote: > >multiple frontend nodes, etc. One of the issue is directly related to > >the current lack of ability to force to close a connection from HTTP > >rules, but

Re: [ANNOUNCE] haproxy-3.0-dev1

Willy, On 1/6/24 15:08, Willy Tarreau wrote: multiple frontend nodes, etc. One of the issue is directly related to the current lack of ability to force to close a connection from HTTP rules, but even without rules, it makes sense to be able to say that This feature request of mine is

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