On Mon, Jan 21, 2019 at 03:28:35PM +0100, Frederic Lecaille wrote:
> On 1/19/19 8:53 AM, Willy Tarreau wrote:
> > I was interested in backporting them to 1.8 once we have more experience
> > with them and they're better organized, so that we avoid backporting
> > reorg patches. I'd say we've made
On Wed, Jan 23, 2019 at 09:37:46PM +0100, Aleksandar Lazic wrote:
>
> Am 23.01.2019 um 21:27 schrieb Willy Tarreau:
> > On Wed, Jan 23, 2019 at 09:08:00PM +0100, Aleksandar Lazic wrote:
> >> Should it be possible to have fe with h1 and be server h2(alpn h2), as I
> >> expect this or similar
Am 23.01.2019 um 21:27 schrieb Willy Tarreau:
> On Wed, Jan 23, 2019 at 09:08:00PM +0100, Aleksandar Lazic wrote:
>> Should it be possible to have fe with h1 and be server h2(alpn h2), as I
>> expect this or similar return value when I go thru haproxy?
>
> Yes absolutely. That's even what I'm
On 1/23/2019 8:16 AM, Marco Colli wrote:
1. Based on advanced conditions (e.g. current user) our Rails
application decides whether to return a normal response (e.g. 2xx) or
a 429 (Too Many Requests); it can also return other errors, like 401
2. HAProxy bans clients if they produce too many 4xx
On Wed, Jan 23, 2019 at 09:08:00PM +0100, Aleksandar Lazic wrote:
> Should it be possible to have fe with h1 and be server h2(alpn h2), as I
> expect this or similar return value when I go thru haproxy?
Yes absolutely. That's even what I'm doing on my tests to try to fix
the issues reported by
Hi Willy.
Am 23.01.2019 um 19:50 schrieb Willy Tarreau:
> Hi Aleks,
>
> On Wed, Jan 23, 2019 at 06:58:25PM +0100, Aleksandar Lazic wrote:
>> backend be_generic_tcp
>> mode http
>> balance source
>> timeout check 5s
>> option tcp-check
>>
>> server "${SERVICE_NAME}"
śr., 23 sty 2019 o 11:53 Janusz Dziemidowicz napisał(a):
> 1.14.2 is current version in Debian testing. Debian seems reluctant to
> use "mainline" nginx versions (1.15.x) so 1.14.x might end in Debian
> 10. I'll try to file Debian bug report later today.
Hi Aleks,
On Wed, Jan 23, 2019 at 06:58:25PM +0100, Aleksandar Lazic wrote:
> backend be_generic_tcp
> mode http
> balance source
> timeout check 5s
> option tcp-check
>
> server "${SERVICE_NAME}" ${SERVICE_DEST_IP}:${SERVICE_DEST_PORT} check
> inter 5s proto h2 ssl ssl-min-ver
Hi Baptiste,
On Wed, Jan 23, 2019 at 02:00:58PM +0100, Baptiste wrote:
> Hi Willy,
>
> Please find attached to this email a set of 4 patches which add a new HTTP
> action that can use a dns resolver section to perform a DNS resolution
> based on the output of a fetch.
> The use case is split DNS
Hi.
After some tricky stuff with centos I switched to debian as base image and was
now able to build haproxy with boringssl.
/usr/local/sbin/haproxy -vv
HA-Proxy version 1.9.2 2019/01/16 - https://haproxy.org/
Build options :
TARGET = linux2628
CPU = generic
CC = gcc
Hi Willy,
This is all very good to hear. I'm glad you were able to get to the bottom of
it all!
Feel free to send along patches if you want me to test before the 1.9.3
release. I'm more than happy to do so.
Best,
Luke
—
Luke Seelenbinder
Stadia Maps | Founder
stadiamaps.com
‐‐‐
Hi Luke,
On Wed, Jan 23, 2019 at 10:47:33AM +, Luke Seelenbinder wrote:
> We were using http-reuse always and experiencing this
> issue (as well as getting 80+% connection reuse). When I scaled it back to
> http-reuse safe, the frequency of this issue seemed to be much lower.
> (Perhaps
Hi,
I didn't think about such trick, it works!
Thank a lot!
On 23/01/2019 11:48, Jarno Huuskonen wrote:
Hi,
On Wed, Jan 23, Thomas Hilaire wrote:
Hi,
I want to implement a rate-limit system using the sticky table of
HAProxy. Consider that I have 100 servers, and a limit of 10
requests per
Hello!
I use HAProxy in front of a web app / service and I would like to add DDoS
protection and rate limiting. The problem is that each part of the
application has different request rates and for some customers we must
accept very hight request rates and burst, while this is not allowed for
Hi Willy,
Please find attached to this email a set of 4 patches which add a new HTTP
action that can use a dns resolver section to perform a DNS resolution
based on the output of a fetch.
The use case is split DNS situations or with highly dynamic environment
where servers behind HAProxy are just
śr., 23 sty 2019 o 10:41 Lukas Tribus napisał(a):
> > I tested all my servers and I've noticed that nginx is broken too. I
> > am running nginx 1.14.2 with OpenSSL 1.1.1a The nginx source contains
> > exactly the same function as haproxy:
> >
Hi,
On Wed, Jan 23, Thomas Hilaire wrote:
> Hi,
>
> I want to implement a rate-limit system using the sticky table of
> HAProxy. Consider that I have 100 servers, and a limit of 10
> requests per server, the ACL would be:
>
> http-request track-sc0 int(1) table GlobalRequestsTracker
>
Hi Willy,
> When using "http-reuse always" the issue disappears and I
> can never get any issue at all. Now that I've fixed this, I'm seeing the
> issue with the SD flags.
Now that's interesting. We were using http-reuse always and experiencing this
issue (as well as getting 80+% connection
On Wed, Jan 23, 2019 at 10:40:09AM +0100, Lukas Tribus wrote:
> Also, we need a big fat warning that all TLSv1.3 users must upgrade in
> the next 1.8 and 1.9 stable version announcement containing this fix.
That's a good point, this will also encourage distro maintainers to
update their versions.
On Wed, Jan 23, 2019 at 11:09:53AM +0100, Willy Tarreau wrote:
> On Wed, Jan 23, 2019 at 09:24:19AM +, Luke Seelenbinder wrote:
> > > I've place an nginx instance after my local haproxy dev config, and
> > > found something which might explain what you're observing : the process
> > >
Hi,
I want to implement a rate-limit system using the sticky table of
HAProxy. Consider that I have 100 servers, and a limit of 10 requests
per server, the ACL would be:
http-request track-sc0 int(1) table GlobalRequestsTracker
http-request deny deny_status 429 if {
On Wed, Jan 23, 2019 at 09:24:19AM +, Luke Seelenbinder wrote:
> > I've place an nginx instance after my local haproxy dev config, and
> > found something which might explain what you're observing : the process
> > apparently leaks FDs and fails once in a while, causing 500 to be returned :
>
Hi Lukas.
Am 23.01.2019 um 10:24 schrieb Luke Seelenbinder:
> Hi Willy,
>
> Thanks for continuing to look into this.
>
>>
>
>> I've place an nginx instance after my local haproxy dev config, and
>> found something which might explain what you're observing : the process
>> apparently leaks FDs
On Wed, 23 Jan 2019 at 09:52, Willy Tarreau wrote:
>
> On Wed, Jan 23, 2019 at 12:07:04AM -0800, Dirkjan Bussink wrote:
> > Of course, you're right. New version of the patch attached!
>
> Now merged, thank you!
It's obvious, but because the commit message doesn't not explicitly mention it:
This
Hi Willy,
Thanks for continuing to look into this.
>
> I've place an nginx instance after my local haproxy dev config, and
> found something which might explain what you're observing : the process
> apparently leaks FDs and fails once in a while, causing 500 to be returned :
That's
On Wed, Jan 23, 2019 at 12:07:04AM -0800, Dirkjan Bussink wrote:
> Of course, you're right. New version of the patch attached!
Now merged, thank you!
Willy
Hi Willy,
On 22 Jan 2019, at 23:17, Willy Tarreau wrote:
>
> As you can see it will enable this code when SSL_OP_NO_RENEGOTIATION=0,
> which is what BoringSSL does and it needs this code to be disabled. Thus
> I think it's better to simply do this :
>
> +#ifndef SSL_OP_NO_RENEGOTIATION
> +
27 matches
Mail list logo
