Re: [PATCH 0/1] Implement new sample fetch method to get the curve name used in key agreement

On Fri, Jul 14, 2023 at 02:59:52AM -0500, Mariam John wrote: > This is an implementation of feature request > [#2165](https://github.com/haproxy/haproxy/issues/2165), > to get the EC curve name used during the key agreement in OpenSSL. This patch > includes the following > changes: > - new

Re: [PATCH] BUILD: ssl: Build with new cryptographic library AWS-LC

Andrew, I could not find how to enable "DHE-RSA-AES256-GCM-SHA384" on aws-lc (required by haproxy vtest) *** h3 debug|[ALERT] (7370) : config : Proxy 'ssl-dhfile-lst': unable to set SSL cipher list to 'DHE-RSA-AES256-GCM-SHA384' for bind

Re: [PATCH] BUILD: ssl: Build with new cryptographic library AWS-LC

Hi Alex, Andrew, On Thu, Jul 13, 2023 at 11:54:44AM +0200, Aleksandar Lazic wrote: > On 2023-07-13 (Do.) 08:22, Hopkins, Andrew wrote: > > * Do you plan to add quic (Server part) faster then OpenSSL? > > > > I have not looked into quic benchmarks but it uses the same > > cryptographic primitives

Re: Old style OCSP not working anymore?

Hi, On 2023-07-14 01:56, Shawn Heisey wrote: On 7/13/23 09:01, Sander Klein wrote: I tried upgrading from 2.6.14 to 2.8.1, but after the upgrade I couldn't connect to any of the sites behind it. While looking at the error it seems like OCSP is not working anymore. Right now I have a setup

Re: Old style OCSP not working anymore?

On 7/13/23 17:56, Shawn Heisey wrote: I do still use this script on one of my servers where I can't get haproxy's built-in ocsp updating to work right.  It is haproxy 2.8.1. A few minutes ago, I fixed the problem on that server with haproxy's built-in OCSP updater, so the script is officially

Re: Wierd issue with OCSP updating

On 7/13/23 15:00, Cyril Bonté wrote: Hi Shawn, Le 13/07/2023 à 18:48, Shawn Heisey a écrit : Looks like on my last edit I deleted it and didn't add it to defaults, so I was wrong in what I said.  It throws a different error when added to defaults: Because it should be in the global section,

Re: Old style OCSP not working anymore?

On 7/13/23 09:01, Sander Klein wrote: I tried upgrading from 2.6.14 to 2.8.1, but after the upgrade I couldn't connect to any of the sites behind it. While looking at the error it seems like OCSP is not working anymore. Right now I have a setup in which I provision the certificates with the

Re: Wierd issue with OCSP updating

Hi Shawn, Le 13/07/2023 à 18:48, Shawn Heisey a écrit : Looks like on my last edit I deleted it and didn't add it to defaults, so I was wrong in what I said.  It throws a different error when added to defaults: elyograg@bilbo:~$ sudo haproxy -dD -c -f /etc/haproxy/haproxy.cfg [NOTICE]  

Re: Wierd issue with OCSP updating

On 7/12/23 04:13, Remi Tricot-Le Breton wrote: On 11/07/2023 22:22, Shawn Heisey wrote: On 7/11/23 01:30, Remi Tricot-Le Breton wrote: That directive didn't work in "global" but it was accepted when I moved it to "defaults".  But it didn't change the behavior.  IPv6 is completely disabled on

Re: [PATCH] BUILD: ssl: Build with new cryptographic library AWS-LC

y 12, 2023 1:14 AM *To:* Hopkins, Andrew; haproxy@formilux.org *Subject:* RE: [EXTERNAL][PATCH] BUILD: ssl: Build with new cryptographic library AWS-LC CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender

Re: [PATCH] BUILD: ssl: Build with new cryptographic library AWS-LC

tps://github.com/aws/aws-lc-rs > [4] https://github.com/aws/aws-lc/issues/804 > > Thanks, Andrew > > -- > *From:* Aleksandar Lazic > *Sent:* Wednesday, July 12, 2023 1:14 AM > *To:* Hopkins, Andrew; haproxy@formilux.org > *Subject:* RE: [EXTERNAL

Re: [PATCH] BUILD: ssl: Build with new cryptographic library AWS-LC

537027817/jobs/10105411198?pr=1#step:15:215 > > > From: Илья Шипицин > Sent: Wednesday, July 12, 2023 12:53 AM > To: Hopkins, Andrew > Cc: haproxy@formilux.org > Subject: RE: [EXTERNAL][PATCH] BUILD: ssl: Build with new cryptographic > library AWS-LC > > >CAUTION:

Re: [PATCH] BUILD: ssl: Build with new cryptographic library AWS-LC

4 AM To: Hopkins, Andrew; haproxy@formilux.org Subject: RE: [EXTERNAL][PATCH] BUILD: ssl: Build with new cryptographic library AWS-LC CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is sa

Re: [PATCH] BUILD: ssl: Build with new cryptographic library AWS-LC

537027817/jobs/10105411198?pr=1#step:15:215 > > > From: Илья Шипицин > Sent: Wednesday, July 12, 2023 12:53 AM > To: Hopkins, Andrew > Cc: haproxy@formilux.org > Subject: RE: [EXTERNAL][PATCH] BUILD: ssl: Build with new cryptographic > library AWS-LC > > >

Re: [PATCH] BUILD: ssl: Build with new cryptographic library AWS-LC

c/pull/1091 [1]  https://github.com/andrewhop/haproxy/actions/runs/5537027817/jobs/10105411198?pr=1#step:15:215 From: Илья Шипицин Sent: Wednesday, July 12, 2023 12:53 AM To: Hopkins, Andrew Cc: haproxy@formilux.org Subject: RE: [EXTERNAL][PATCH] BUILD: ssl: Build with new cryptographic library

Re: Wierd issue with OCSP updating

On 11/07/2023 22:22, Shawn Heisey wrote: On 7/11/23 01:30, Remi Tricot-Le Breton wrote: The OCSP update mechanism uses the internal http_client which then uses the resolvers. The only time when I had some strange resolver-related issues is when the name resolution returned IPv6 addresses

Re: [PATCH] BUILD: ssl: Build with new cryptographic library AWS-LC

Hi Andrew. On 2023-07-12 (Mi.) 02:26, Hopkins, Andrew wrote: Hello HAProxy maintainers, I work on the AWS libcrypto (AWS-LC) project [1]. Our goal is to improve the cryptography we use internally at AWS and help our customers externally. In the spirit of helping people use good crypto we know

Re: [PATCH] BUILD: ssl: Build with new cryptographic library AWS-LC

Hello, Andrew! you already tried to launch CI in fork [PATCH] Minor: ssl: Build with new cryptographic library AWS-LC by andrewhop · Pull Request #1 · andrewhop/haproxy (github.com) please make sure you've enabled GHA for fork (here: Actions ·

Re: Wierd issue with OCSP updating

On 7/11/23 01:30, Remi Tricot-Le Breton wrote: The OCSP update mechanism uses the internal http_client which then uses the resolvers. The only time when I had some strange resolver-related issues is when the name resolution returned IPv6 addresses which were not properly managed on my machine.

Re: Wierd issue with OCSP updating

On 10/07/2023 22:41, Shawn Heisey wrote: On 7/8/23 21:33, Shawn Heisey wrote: Here's the very weird part.  It seems that haproxy is sending the OCSP request to localhost, not the http://r3.o.lencr.org URL that it SHOULD be sending it to. Right before the above log entry is this one: Jul 

Re: Wierd issue with OCSP updating

On 7/8/23 21:33, Shawn Heisey wrote: Here's the very weird part.  It seems that haproxy is sending the OCSP request to localhost, not the http://r3.o.lencr.org URL that it SHOULD be sending it to.  Right before the above log entry is this one: Jul  8 21:15:38 - haproxy[4075] 127.0.0.1:57696

Re: Wierd issue with OCSP updating

On 7/8/23 21:33, Shawn Heisey wrote: Here's the very weird part.  It seems that haproxy is sending the OCSP request to localhost, not the http://r3.o.lencr.org URL that it SHOULD be sending it to.  Right before the above log entry is this one: Jul  8 21:15:38 - haproxy[4075] 127.0.0.1:57696

Re: OCSP update mechanism startup

On 07/07/2023 18:24, Willy Tarreau wrote: On Fri, Jul 07, 2023 at 03:42:58PM +, Tristan wrote: Also personally I have never understood the point of default server certs... besides getting unwanted attention from censys/shodan/etc... I remember some users who were hosting many

Re: OCSP update mechanism startup

On Fri, Jul 07, 2023 at 03:42:58PM +, Tristan wrote: > Also personally I have never understood the point of default server certs... > besides getting unwanted attention from censys/shodan/etc... I remember some users who were hosting many applications from internal subsidiaries wanted to make

Re: OCSP update mechanism startup

On 07/07/2023 16:34, Willy Tarreau wrote: On Fri, Jul 07, 2023 at 03:06:52PM +, Tristan wrote: The ocsp-update option should be between brackets /etc/haproxy/ssl/mangadex.dev.pem [ocsp-update on] mangadex.dev *.mangadex.dev Oh that makes more sense indeed; should have guessed so since

Re: OCSP update mechanism startup

On Fri, Jul 07, 2023 at 03:06:52PM +, Tristan wrote: > > The ocsp-update option should be between brackets > > /etc/haproxy/ssl/mangadex.dev.pem [ocsp-update on] mangadex.dev > > *.mangadex.dev > > Oh that makes more sense indeed; should have guessed so since other crt-list > bind params used

Re: OCSP update mechanism startup

The ocsp-update option should be between brackets /etc/haproxy/ssl/mangadex.dev.pem [ocsp-update on] mangadex.dev *.mangadex.dev Oh that makes more sense indeed; should have guessed so since other crt-list bind params used those indeed... - does the OCSP update mechanism update the files

Re: QUIC (mostly) working on top of unpatched OpenSSL

currently, it is client support for QUIC openssl/CHANGES.md at master · openssl/openssl · GitHub пт, 7 июл. 2023 г. в 10:58, Aleksandar Lazic : > Hi. > > Just a addendum below to my last mail. > > On 2023-07-07 (Fr.) 00:33, Aleksandar

Re: QUIC (mostly) working on top of unpatched OpenSSL

On Fri, 7 Jul 2023 at 00:26, Tristan wrote: > > Hi Willy, > > Thanks for sharing that. First, I'm amazed that such a hacky method > works well-enough to get QUIC (nearly-fully) working. > > Now for your concerns... Honestly, I agree with you and really don't > want to see a brand new protocol

Re: QUIC (mostly) working on top of unpatched OpenSSL

Hi. Just a addendum below to my last mail. On 2023-07-07 (Fr.) 00:33, Aleksandar Lazic wrote: Hi Willy On 2023-07-06 (Do.) 22:05, Willy Tarreau wrote: Hi all, as the subject says it, Fred managed to make QUIC mostly work on top of a regular OpenSSL. Credit goes to the NGINX team who found a

Re: QUIC (mostly) working on top of unpatched OpenSSL

interesting. I think, I can try run QUIC Interop locally to compare against QuicTLS чт, 6 июл. 2023 г. в 22:08, Willy Tarreau : > Hi all, > > as the subject says it, Fred managed to make QUIC mostly work on top of > a regular OpenSSL. Credit goes to the NGINX team who found a clever and >

Re: QUIC (mostly) working on top of unpatched OpenSSL

Hi Willy On 2023-07-06 (Do.) 22:05, Willy Tarreau wrote: Hi all, as the subject says it, Fred managed to make QUIC mostly work on top of a regular OpenSSL. Credit goes to the NGINX team who found a clever and absolutely ugly way to abuse OpenSSL callbacks to intercept and inject data from/to

Re: QUIC (mostly) working on top of unpatched OpenSSL

Hi Willy, Thanks for sharing that. First, I'm amazed that such a hacky method works well-enough to get QUIC (nearly-fully) working. Now for your concerns... Honestly, I agree with you and really don't want to see a brand new protocol compromised on. Whether one calls it "ossification" or

Re: OCSP update mechanism startup

Hello Tristan, On 06/07/2023 13:24, Tristan wrote: Hello, I'm trying to make use of the new ocsp-update mechanism, and finding no success (yet). I've migrated my crt bind arguments to a crt-list argument (+ relevant file) and that loads in and gets used fine, but despite having

Re: Some notes about what happens with HTTP/1.0 requests

On 7/5/23 15:27, Pavlos Parissis wrote: There is a list of pre-defined ACLs, see http://docs.haproxy.org/2.8/configuration.html#7.4, and in that list you have HTTP_1.0 acl to match traffic for that version of HTTP protocol. So, you can add below snippet to block traffic for HTTP 1.0 version

Re: Some notes about what happens with HTTP/1.0 requests

On Wednesday, July 5, 2023 8:25:35 PM CEST Shawn Heisey wrote: > I have a backend in haproxy for my Solr server. Solr lives unencrypted > on port 8983, haproxy provides TLS for it, on a name like > `solr.example.com`. > > Everything works fully as expected with HTTP 1.1, 2, or 3. > > If I

Re: [PR] Implement fetch for arbitrary TLV payloads

Hi Alexander, On Fri, Jun 30, 2023 at 02:36:22PM +, Stephan, Alexander wrote: > Dear list, > > This PR request was not meant to be sent to the upstream repository. > Furthermore, this is not ready to receive any maintainer feedback yet. > > I accidentally selected the wrong base repository

RE: [PR] Implement fetch for arbitrary TLV payloads

-pr-bot-no-re...@ltri.eu. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Dear list! Author: Alexander Stephan Number of patches: 1 This is an automated relay of the Github pull request: Implement fetch for arbitrary TLV payloads Patch title(s): Fully

Re: [ANNOUNCE] haproxy-2.7.9

Willy, On 6/9/23 15:16, Christopher Faulet wrote: Indeed, it is a good point. I planned to emit a new 2.2 release on next Monday. I'll warn about the new status of the 2.2 branch. I let willy do the site update. I don't want to bug you in your holidays, however I'd like to note that the

Re: Is tune.quic.backend.max-idle-timeout missing from the documentation?

On 6/28/23 08:17, Nick Ramirez wrote: The HAProxy source code indicates that there is a directive named 'tune.quic.backend.max-idle-timeout': haproxy/src/cfgparse-quic.c at f473eb72066e02d44837fd77110b6ca5bdea97e2 · haproxy/haproxy (github.com)

Re: haproxy indefinitely delays the delivery of small http chunks with slz

e problem occurred there for a realistic setup (couchdb >> with HAProxy in front configured to do compression). > > Excellent, thanks! I'll merge them both to the libslz project and to > haproxy. > >> The CouchDB project are considering adding a WebSocket option for this >> end

Re: haproxy indefinitely delays the delivery of small http chunks with slz

Hi Tim, On Wed, Jun 28, 2023 at 04:12:57PM +0200, Tim Düsterhus wrote: > Hi > > On 6/23/23 13:14, Willy Tarreau wrote: > > But you're aware that what you're asking for is a direct violation of > > basic HTTP messaging rules stating that no agent may depend on chunk > > delivery due to anything

Re: haproxy indefinitely delays the delivery of small http chunks with slz

Hi On 6/23/23 13:14, Willy Tarreau wrote: But you're aware that what you're asking for is a direct violation of basic HTTP messaging rules stating that no agent may depend on chunk delivery due to anything along the chain possibly having to buffer some of the data for analysis or

Re: haproxy indefinitely delays the delivery of small http chunks with slz

for a realistic setup (couchdb > with HAProxy in front configured to do compression). Excellent, thanks! I'll merge them both to the libslz project and to haproxy. > The CouchDB project are considering adding a WebSocket option for this > endpoint in light of the re-realisation that we've

Re: School Districts Contacts 2023

Hi there, We are excited to offer you a comprehensive email list of school districts that includes key contact information such as phone numbers, email addresses, mailing addresses, company revenue, size, and web addresses. Our databases also cover related industries such as: * K-12

Re: haproxy indefinitely delays the delivery of small http chunks with slz

project are considering adding a WebSocket option for this endpoint in light of the re-realisation that we've been living in HTTP sin this whole time. Your patches are most welcome as they mean users can keep doing what they've always been doing and can upgrade HAProxy without having to make any

Re: VULNERABILITY REPORT Email Spoofing Due to Weak SPF

*Hi There Team,* *Hope you are doing well,* Kindly update me regarding this vulnerability and I am hoping for a bug bounty from you for sending this vulnerability ethically to you. *Best,* On Sat, Jun 10, 2023 at 12:37 AM Muhammad Umar wrote: > I am a security researcher and I have found this

Re: haproxy indefinitely delays the delivery of small http chunks with slz

Hi Robert, On Sat, Jun 24, 2023 at 09:48:31PM +0100, Robert Newson wrote: > Hi, > > That sounds great, much appreciated. I'll be available all week to test any > patches you might propose. I gave it a try. There was already a flush call in the data block processing (I don't know why, to be

Re: haproxy indefinitely delays the delivery of small http chunks with slz

Hi, That sounds great, much appreciated. I'll be available all week to test any patches you might propose. B. > On 24 Jun 2023, at 21:35, Willy Tarreau wrote: > > Hi Robert, > > On Sat, Jun 24, 2023 at 08:39:22PM +0100, Robert Newson wrote: >> So, the behaviour of the _changes endpoint when

Re: haproxy indefinitely delays the delivery of small http chunks with slz

Hi Robert, On Sat, Jun 24, 2023 at 08:39:22PM +0100, Robert Newson wrote: > So, the behaviour of the _changes endpoint when used with the feed=continuous > and heartbeat=X (where X is number of milliseconds) is as follows; > > 1) when _changes is invoked, couchdb opens its internal "docs in

Re: haproxy indefinitely delays the delivery of small http chunks with slz

Hi, Agree there are limitations to the various workarounds in my previous response, the only one that I'm confident in is disabling compression for these responses (for our particular setup only). So, the behaviour of the _changes endpoint when used with the feed=continuous and heartbeat=X

Re: haproxy indefinitely delays the delivery of small http chunks with slz

Hi Robert, On Fri, Jun 23, 2023 at 11:33:37PM +0100, Robert Newson wrote: > Hi, > > I underestimated. the heartbeat option was added back in 2009, 14 years ago, > but I don't want to fixate on whether we made this mistake long enough ago to > justify distorting HAProxy. OK! > The CouchDB dev

Re: [PATCH] DOC: Attempt to fix dconv parsing error for tune.h2.fe.initial-window-size

Hi all, Le 20/06/2023 à 11:57, Amaury Denoyelle a écrit : On Tue, Jun 13, 2023 at 03:18:19PM +0200, Tim Düsterhus, WoltLab GmbH wrote: Hi please find the patch attached. This email address is not subscribed to the list, please keep it in Cc when replying. Thanks Tim, I applied all of your

Re: haproxy indefinitely delays the delivery of small http chunks with slz

transported data, and as such they're > not supposed to be forwarded 1-to-1. In practice most intermediaries > will proceed as recommended, which is to advertise the known length of > pending data, so the output data will appear re-chunked to buffer-size > chunks. But of course no r

Re: haproxy indefinitely delays the delivery of small http chunks with slz

length of pending data, so the output data will appear re-chunked to buffer-size chunks. But of course no reordering is permitted. The real goal of chunks is only to permit to indicate the end of a body whose initial size was not known at header time, without closing, That's why usually chunks are

Re: haproxy indefinitely delays the delivery of small http chunks with slz

Hi Willy, thank you for this response. The behaviour in CouchDB is ancient (12 years plus, essentially since before the 1.0 release), and yes it is clearly a bit naughty, though it has also worked up to this point for us. The reason I raised this here is because it seemed inadvertent given the

Re: haproxy indefinitely delays the delivery of small http chunks with slz

Hi Robert, On Fri, Jun 23, 2023 at 11:01:30AM +0100, Robert Newson wrote: > Hi, > > We use HAProxy in front of Apache CouchDB. CouchDB has an endpoint with some > interesting characteristics called _changes. With certain parameters, that > are commonly used, the response is effectively endless,

RE: VoIP dataset for your marketing campaign

Hello, I'm writing to follow up on my latest email. I still haven't heard back from you and was wondering if you have had the time to consider my proposal. It would be great to hear back from you. So, please let me know when you find some time. Regards, Lalaine Loffer On 06/05/2023, Lalaine

RE: [PATCH 1/1] MEDIUM: ssl: new sample fetch method to get curve name

: [EXTERNAL] Re: [PATCH 1/1] MEDIUM: ssl: new sample fetch method to get curve name Hi. On 2023-06-20 (Di.) 18:50, Mariam John wrote: > Adds a new sample fetch method to get the curve name used in the > key agreement to enable better observability. In OpenSSLv3, the fu

Re: [PATCH 0/1] Implement new sample fetch method to get the curve name used in key agreement

Hello Mariam, On Tue, Jun 20, 2023 at 11:50:51AM -0500, Mariam John wrote: > This is an implementation of feature request > [#2165](https://github.com/haproxy/haproxy/issues/2165), > to get the EC curve name used during the key agreement in OpenSSL. This patch > includes the following >

Re: Performance cost of using Lua for service discovery

Hi, For something similar, I in fact use the admin socket to haproxy to add drain and remove servers from backend definitions. Very light and doesn't use CPU on the haproxy machine. On 21 June 2023 02:29:42 GMT+02:00, Diffie wrote: >Hello! > >I had a question about the performance of Lua in

Re: [PATCH 1/1] MEDIUM: ssl: new sample fetch method to get curve name

Hi. On 2023-06-20 (Di.) 18:50, Mariam John wrote: Adds a new sample fetch method to get the curve name used in the key agreement to enable better observability. In OpenSSLv3, the function `SSL_get_negotiated_group` returns the NID of the curve and from the NID, we get the curve name by passing

Re: [PATCH] DOC: Attempt to fix dconv parsing error for tune.h2.fe.initial-window-size

On Tue, Jun 13, 2023 at 03:18:19PM +0200, Tim Düsterhus, WoltLab GmbH wrote: > Hi > please find the patch attached. > This email address is not subscribed to the list, please keep it in Cc > when replying. Thanks Tim, I applied all of your patches. On a side note, I noticed on the rendered doc

Re: [PATCH] DOC: Attempt to fix dconv parsing error for tune.h2.fe.initial-window-size

Hi On 6/13/23 15:18, Tim Düsterhus, WoltLab GmbH wrote: please find the patch attached. This email address is not subscribed to the list, please keep it in Cc when replying. Ping :-) There's also a second patch email I sent around the same time where I'm not sending a second ping to reduce

Re: SPOE

On 2023-06-15 22:11, Sander Klein wrote: Hi, Is there a way to filter which URL's go through SPOE and which are just handled directly in a single frontend? I can't seem to find it in the documentantion. I'm currently on HAProxy 2.6.14. Right after I mailed this I read SPOE.txt a bit better

Re: net::ERR_INCOMPLETE_CHUNKED_ENCODING / malformed HTTP packet.

Small update, we went back as far as HAProxy v2.4.22 and the issue still persists. If we swap out HAProxy for Nginx reverse proxy, it also works fine.

Re: [ANNOUNCE] haproxy-2.7.9

Le 6/9/23 à 09:45, Tim Düsterhus a écrit : Hi On 6/7/23 18:57, Christopher Faulet wrote: If you are running a 2.7, please upgrade. But keep in mind it is not a LTS version. Now the 2.8.0 was released, it could be good to start to evaluate it. However keep cool, there is no rush to upgrade. You

Re: [ANNOUNCE] haproxy-2.7.9

Hi On 6/7/23 18:57, Christopher Faulet wrote: If you are running a 2.7, please upgrade. But keep in mind it is not a LTS version. Now the 2.8.0 was released, it could be good to start to evaluate it. However keep cool, there is no rush to upgrade. You have 1 year to do so ;) That reminds me:

Re: regression? scheme and hostname logged with %r with 2.6.13

Hi, Yeah I addressed this with "%HM %HPO%HQ %HV" which looks right in my logs under some light testing, but I will check the pathq option also. B. > On 7 Jun 2023, at 22:39, Lukas Tribus wrote: > > Hello, > > > yes, H2 behaves very differently; due to protocol differences but also > due to

Re: regression? scheme and hostname logged with %r with 2.6.13

Hello, yes, H2 behaves very differently; due to protocol differences but also due to other changes. In the beginning H2 was only implemented in the frontend and every transaction was downgraded to HTTP/1.1 internally. This was later changed to an internal generic "HTX" representation that

re: regression? scheme and hostname logged with %r with 2.6.13

Hi, Figured this out (my reply might not be threaded, the mailing list daemon doesn't add me after I confirm my subscription) It was https://github.com/haproxy/haproxy/commit/30ee1efe676e8264af16bab833c621d60a72a4d7 in haproxy 2.1 that caused this change. It's deliberate but the documentation

Re: [PATCH] DOC: quic: fix misspelled tune.quic.socket-owner

Hello Willy,  I understand, thank you for the explanation. Have a nice holidays ! ;) Le 07/06/2023 à 14:55, Willy Tarreau a écrit : Hello Artur, On Tue, Jun 06, 2023 at 03:18:31PM +0200, Artur wrote: About the backporting instructions I was not sure how far it should be backported. I

Re: maint, drain: the right approach

Hi Willy, > > Seems that it's considered an expected behavior to consider > > optimistically the server as UP > > when leaving MAINT mode, even if the L4 health checks are not completed > > yet. > Normally using the existing API you could forcefully > mark the server's check as down using

Re: Contribute to HaProxy

Hi Umesh, On Fri, Jun 02, 2023 at 10:27:48AM +0530, umesh patel wrote: > Hi There, > > I am looking for SCTP protocol based load balancer. I see that HaProxy has > a solid platform for TCP load balancing. However, SCTP is not supported. I > would like to develop and contribute to HaProxy SCTP

Re: [PATCH] DOC: quic: fix misspelled tune.quic.socket-owner

Hello Artur, On Tue, Jun 06, 2023 at 03:18:31PM +0200, Artur wrote: > About the backporting instructions I was not sure how far it should be > backported. I preferred to skip it instead of giving an erroneous > instruction. > Maybe someone can explain if this backport instruction is really

Re: Homepage and banner links

do you want links please let me know? [image: Mailtrack] Sender notified by Mailtrack 06/06/23, 03:13:30 PM

Re: [PATCH] DOC: quic: fix misspelled tune.quic.socket-owner

Le 06/06/2023 à 14:52, Amaury Denoyelle a écrit : Do not hesitate to give us feedback if you test QUIC support :) Yes, I will. I deployed haproxy+quic (recommended setup) on one site with some trafic so I need few days to get visitors' feedback, if any. At this point I can't see anything

Re: [PATCH] DOC: quic: fix misspelled tune.quic.socket-owner

Hello Tim, Thank you for your help. I forgot to include patch description in the body. My bad. Luckily Amaury was there. :) About the backporting instructions I was not sure how far it should be backported. I preferred to skip it instead of giving an erroneous instruction. Maybe someone can

Re: [PATCH] DOC: quic: fix misspelled tune.quic.socket-owner

Hi On 6/6/23 15:05, Amaury Denoyelle wrote: In fact, I already merged the patch. The commit message was already provided as the email body so I integrated it directly into the patch. Yeah, I've seen your email shortly after I sent mine. As for backport information, most of the time we skip

Re: [PATCH] DOC: quic: fix misspelled tune.quic.socket-owner

On Tue, Jun 06, 2023 at 02:54:19PM +0200, Tim Düsterhus wrote: > Hi Artur, > On 6/6/23 14:42, Artur wrote: > > DOC: quic: fix misspelled tune.quic.socket-owner > > > Commit 511ddd5 introduced tune.quic.socket-owner parameter > > related to QUIC socket behaviour. > > However it was misspelled in

Re: [PATCH] DOC: quic: fix misspelled tune.quic.socket-owner

Hi Artur, On 6/6/23 14:42, Artur wrote: DOC: quic: fix misspelled tune.quic.socket-owner Commit 511ddd5 introduced tune.quic.socket-owner parameter related to QUIC socket behaviour. However it was misspelled in configuration.txt in 'bind' section as tune.quic.conn-owner. I'm not a

Re: [PATCH] DOC: quic: fix misspelled tune.quic.socket-owner

On Tue, Jun 06, 2023 at 02:42:37PM +0200, Artur wrote: > DOC: quic: fix misspelled tune.quic.socket-owner > Commit 511ddd5 introduced tune.quic.socket-owner parameter > related to QUIC socket behaviour. > However it was misspelled in configuration.txt in 'bind' section as > tune.quic.conn-owner.

Re: tune.quic.socket-owner misspelled in configuration.txt (bind section)

Hello Amaury, Le 06/06/2023 à 09:30, Amaury Denoyelle a écrit : On Mon, Jun 05, 2023 at 07:21:37PM +0200, Artur wrote: Hello, In the following commit tune.quic.socket-owner parameter is introduced. However, in configuration.txt, line 4629, it's misspelled as tune.quic.conn-owner.

Re: tune.quic.socket-owner misspelled in configuration.txt (bind section)

On Mon, Jun 05, 2023 at 07:21:37PM +0200, Artur wrote: > Hello, > In the following commit tune.quic.socket-owner parameter is introduced. > However, in configuration.txt, line 4629, it's misspelled as > tune.quic.conn-owner. >

Re: Debian + QUIC / HTTP/3

On 6/5/23 01:41, Artur wrote: What is suggested/recommended way to get QUIC / HTTP/3 working in haproxy on Debian ? I have been debating for a while whether or not to get the work I have done on build scripts out into the world. Just mirrored the repo from my gitlab server to github, so

RE: VoIP dataset for your marketing campaign

Hi, Are you interested in purchasing any of the datasets below? Please let me know, I'll provide more information. Thanks a lot! Regards, Lalaine Loffer On 06/01/2023, Lalaine Loffer wrote Hello, Are you interested in acquiring contact information for VoIP users to enhance your marketing

Re: Debian + QUIC / HTTP/3

I think that people use README as landing page. maybe it worth adding docker hub link there ? it is hard for first time user to identify whether docker image(s) exists or not. пн, 5 июн. 2023 г. в 11:57, Artur : > Thank you Илья and Dinko. > > What I can see is that haproxy doc suggest using

Re: OCSP renewal with 2.8

Am 05.06.2023 um 10:08 schrieb William Lallemand: As I explained in my previous mail, the option was not set on the bind lines because of architectural problems, but you could expect to have a way to do it globally in future versions. thanks a lot for this information. I will wait then to have

Re: Debian + QUIC / HTTP/3

Thank you Илья and Dinko. What I can see is that haproxy doc suggest using QuicTLS library. The build process is well explained in Dockerfile. That's perfect. I've also seen some information about haproxy 2.6 configuration for HTTP/3 over QUIC in the following article. I imagine it may be

Re: Debian + QUIC / HTTP/3

There're at least "build from source" haproxy/INSTALL at master · haproxy/haproxy (github.com) "use docker images" haproxytech's Profile | Docker Hub maybe other ways ? пн, 5 июн. 2023 г. в

Re: OCSP renewal with 2.8

On Sat, 3 Jun 2023 at 14:30, William Lallemand wrote: > That's what we've done in the first place, but I decided to remove it > because I was not happy with the architecture. And once you have > something like this, you have to keep the configuration compatibility > for the next versions and then

Re: OCSP renewal with 2.8

Hello, On Sat, Jun 03, 2023 at 04:28:30PM -0600, Shawn Heisey wrote: > On 6/3/23 15:37, Shawn Heisey wrote: > > On 6/3/23 15:28, Shawn Heisey wrote: > >> So maybe a completely separate global option makes sense.  The > >> crt-list requirement is not really a burden for me, but for someone > >>

Re: OCSP renewal with 2.8

On 6/3/23 15:37, Shawn Heisey wrote: On 6/3/23 15:28, Shawn Heisey wrote: So maybe a completely separate global option makes sense.  The crt-list requirement is not really a burden for me, but for someone who uses a LOT of certificates that change frequently, it probably would become a

Re: OCSP renewal with 2.8

On 6/3/23 15:28, Shawn Heisey wrote: So maybe a completely separate global option makes sense.  The crt-list requirement is not really a burden for me, but for someone who uses a LOT of certificates that change frequently, it probably would become a burden. Unless it is possible to have a

Re: OCSP renewal with 2.8

On 6/2/23 14:42, Lukas Tribus wrote: I suggest we make it configurable on the bind line like other ssl options, so it will work for the common use cases that don't involve crt-lists, like a simple crt statement pointing to a certificate or a directory. It could also be a global option *as

Re: OCSP renewal with 2.8

> On 2023-06-02 (Fr.) 22:42, Lukas Tribus wrote: > > I suggest we make it configurable on the bind line like other ssl > > options, so it will work for the common use cases that don't involve > > crt-lists, like a simple crt statement pointing to a certificate or a > > directory. > > That's what

Re: OCSP renewal with 2.8

On Sat, Jun 03, 2023 at 01:50:48PM +0200, William Lallemand wrote: > On Thu, Jun 01, 2023 at 11:42:34PM +0200, Willy Tarreau wrote: > > So this means that the doc is still not clear enough and we need to > > improve this. And indeed, I'm myself confused because William told me > > a few days ago

Re: OCSP renewal with 2.8

On Fri, Jun 02, 2023 at 09:55:25PM +0200, Willy Tarreau wrote: > On Fri, Jun 02, 2023 at 01:29:31PM +0300, Matthias Fechner wrote: > > Am 02.06.2023 um 04:13 schrieb Shawn Heisey: > > > @Matthias I have no idea whether crt-list can load all certs in a > > > directory like crt can.  If it can't,

Re: OCSP renewal with 2.8

On Thu, Jun 01, 2023 at 11:42:34PM +0200, Willy Tarreau wrote: > So this means that the doc is still not clear enough and we need to > improve this. And indeed, I'm myself confused because William told me > a few days ago that "ocsp-update" was for crt-list lines only and it's > found in the "bind

Re: OCSP renewal with 2.8

Hi. On 2023-06-02 (Fr.) 22:42, Lukas Tribus wrote: On Fri, 2 Jun 2023 at 21:55, Willy Tarreau wrote: Initially during the design phase we thought about having 3 states: "off", "on", "auto", with the last one only enabling updates for certs that already had a .ocsp file. But along discussions

<    4   5   6   7   8   9   10   11   12   13   >