Re: Backport proposal, opinion needed

Am 19-04-2017 13:02, schrieb Pavlos Parissis: On 19/04/2017 12:13 μμ, Willy Tarreau wrote: Hi all, Stephan (in Cc) reported me two nice segfaults in the config parser when feeding haproxy with some horribly fuzzed invalid configurations. To make it clear, it happens only when haproxy

Fix building haproxy-1.7.5 with LibreSSL

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, haproxy 1.7.5 fails to build with LibreSSL 2.5.3. Like OpenSSL, LibreSSL is making structs opaque. Direct access to the members thus leads to build failures. This has been addressed by OpenBSD for 1.6, see

Re: ModSecurity: First integration patches

Am 19-04-2017 11:24, schrieb Thierry Fournier: On 19 Apr 2017, at 09:16, Aleksandar Lazic wrote: Am 19-04-2017 05:51, schrieb Willy Tarreau: On Tue, Apr 18, 2017 at 11:55:46PM +0200, Aleksandar Lazic wrote: Why not reuse the upcoming http/2 format. HTTP/2 is *easy* to

Re: Restricting RPS to a service

Hi Holgar, Thanks once again. However, I understand that session means the same as connection. The rate-limit documentation confirms that: "When the frontend reaches the specified number of new sessions per second, it stops accepting *new connections* until the rate drops below the limit again".

Re: Restricting RPS to a service

Hi Krishna, Krishna Kumar (Engineering) wrote: > Thanks for your response. However, I want to restrict the requests > per second either at the frontend or backend, not session rate. I > may have only 10 connections from clients, but the backends can > handle only 100 RPS. How do I deny or delay

Re: Restricting RPS to a service

Hi Krishna, Krishna Kumar (Engineering) wrote: > What is the way to rate limit on the entire service, without caring > about which client is hitting it? Something like "All RPS should be < > 1000/sec"? You can set a rate limit per frontend (in a frontend section): rate-limit sessions 1000

Re: ModSecurity: First integration patches

Hi, There is a new lot of patches for the spoa/modescurity contrib. Thierry On Wed, 19 Apr 2017 11:24:36 +0200 Thierry Fournier wrote: > > > On 19 Apr 2017, at 09:16, Aleksandar Lazic wrote: > > > > > > > > Am 19-04-2017 05:51, schrieb Willy

Re: Backport proposal, opinion needed

Hi Pavlos, On Wed, Apr 19, 2017 at 01:02:55PM +0200, Pavlos Parissis wrote: > I also believe that it should be backported at least to 1.7 version[1]. > It makes the output more clear and squeaks only the relevant bad config lines. Thanks for your feedback! > [1] IMHO: Users of 1.5 version

Re: Backport proposal, opinion needed

On 19/04/2017 12:13 μμ, Willy Tarreau wrote: > Hi all, > > Stephan (in Cc) reported me two nice segfaults in the config parser when > feeding haproxy with some horribly fuzzed invalid configurations. To make > it clear, it happens only when haproxy *fails* to start due to an error. > But it's not

Restricting RPS to a service

Hi Willy, others, I have seen documents that describe how to rate limit from a single client. What is the way to rate limit on the entire service, without caring about which client is hitting it? Something like "All RPS should be < 1000/sec"? Thanks, - Krishna

Re: [PATCH] Fix haproxy hangs on FreeBSD >= 11

On Wed, Apr 19, 2017 at 11:52:22AM +0200, Olivier Houchard wrote: > Hi guys, > > Thanks to your help, we finally figure out what was happening on FreeBSD, > and the attached patch should fix it. > Problem was, haproxy relies on what is really undefined behavior in C, with > signed integer

Backport proposal, opinion needed

Hi all, Stephan (in Cc) reported me two nice segfaults in the config parser when feeding haproxy with some horribly fuzzed invalid configurations. To make it clear, it happens only when haproxy *fails* to start due to an error. But it's not a reason for failing the dirty way. Every time it was a

[PATCH] Fix haproxy hangs on FreeBSD >= 11

Hi guys, Thanks to your help, we finally figure out what was happening on FreeBSD, and the attached patch should fix it. Problem was, haproxy relies on what is really undefined behavior in C, with signed integer overflows. gcc and earlier versions of clang behaved as we expected, but newer

Re: ModSecurity: First integration patches

> On 19 Apr 2017, at 09:16, Aleksandar Lazic wrote: > > > > Am 19-04-2017 05:51, schrieb Willy Tarreau: >> On Tue, Apr 18, 2017 at 11:55:46PM +0200, Aleksandar Lazic wrote: >>> Why not reuse the upcoming http/2 format. >>> HTTP/2 is *easy* to parse and the implementations

Re: [RFC][PATCHES] seamless reload

On Wed, Apr 19, 2017 at 09:58:27AM +0200, Pavlos Parissis wrote: > On 13/04/2017 06:18 μμ, Olivier Houchard wrote: > > On Thu, Apr 13, 2017 at 06:00:59PM +0200, Conrad Hoffmann wrote: > >> On 04/13/2017 05:10 PM, Olivier Houchard wrote: > >>> On Thu, Apr 13, 2017 at 04:59:26PM +0200, Conrad

Re: [RFC][PATCHES] seamless reload

On 13/04/2017 06:18 μμ, Olivier Houchard wrote: > On Thu, Apr 13, 2017 at 06:00:59PM +0200, Conrad Hoffmann wrote: >> On 04/13/2017 05:10 PM, Olivier Houchard wrote: >>> On Thu, Apr 13, 2017 at 04:59:26PM +0200, Conrad Hoffmann wrote: Sure, here it is ;P I now get a segfault (on

Re: ModSecurity: First integration patches

Am 19-04-2017 05:51, schrieb Willy Tarreau: On Tue, Apr 18, 2017 at 11:55:46PM +0200, Aleksandar Lazic wrote: Why not reuse the upcoming http/2 format. HTTP/2 is *easy* to parse and the implementations of servers are growing? Are you kidding ? I mean you want everyone to have to implement