Re: Simply adding a filter causes read error

2018-12-12 Thread flamesea12
Hi, It's 100% reproduciable in my centos 7 PC ### Good Config start # global     maxconn 100     daemon     nbproc 2 defaults     retries 3     option redispatch     timeout client  60s     timeout connect 60s     timeout server  60s     timeout http-request 60s     timeout http-keep-ali

Re: Simply adding a filter causes read error

2018-12-12 Thread Willy Tarreau
Hi, On Thu, Dec 13, 2018 at 03:48:57PM +0900, flamese...@yahoo.co.jp wrote: > Hi again > I tested against v1.8.15, the error's persistent. It's very unclear what type of problem you're experiencing. Do you have a working and a non-working config as a starting point, and a way to reproduce the pro

Re: Simply adding a filter causes read error

2018-12-12 Thread flamesea12
Hi again I tested against v1.8.15, the error's persistent. - Original Message - From: "flamese...@yahoo.co.jp" To: Aleksandar Lazic ; "haproxy@formilux.org" Date: 2018/12/7, Fri 22:59 Subject: Re: Simply adding a filter causes read error Hi Thanks for the reply. I have a t

[ANNOUNCE] haproxy-1.8.15

2018-12-12 Thread Willy Tarreau
Hi, HAProxy 1.8.15 was released on 2018/12/13. It added 69 new commits after version 1.8.14. Yes I know 1.8 has been lagging behind a little bit during these last few months, but all the people able to emit a release were all totally booked on finishing 1.9. So here comes the long-expected 1.8.1

Re: Sporadic problems with backend selection with H2.

2018-12-12 Thread Willy Tarreau
On Wed, Dec 12, 2018 at 11:00:21AM -0700, Sean Reifschneider wrote: > Thanks, that makes sense and I did a quick test with just the Host header > based routing and that was looking good. I don't recall where I got to > both SNI and host selection, that might be something that fixed a problem 3 > y

Re: corruption of data with compression in 1.9-dev10

2018-12-12 Thread PiBa-NL
Hi Christopher, Op 12-12-2018 om 13:49 schreef Christopher Faulet: Le 12/12/2018 à 12:07, Pi Ba a écrit : Found the issue on the 10th (I think commit 56b0348).. so yesterday's commit isn't the (only) problem.. tested with commit 0007d0a the issue also happens. Reverting only below mentioned co

Re: Sporadic problems with backend selection with H2.

2018-12-12 Thread Sean Reifschneider
Thanks, that makes sense and I did a quick test with just the Host header based routing and that was looking good. I don't recall where I got to both SNI and host selection, that might be something that fixed a problem 3 years ago, or might have just been my misunderstanding. Thanks! Sean On Tu

Re: Uptick in 503s with HAProxy 1.8

2018-12-12 Thread Àbéjídé Àyodélé
Hi, Follow up from my previous email, we have new findings and the findings are as below. We observed endpoints that returned 400 with a termination reason of CH in 1.7 now sometimes return a 503 in 1.8 with a termination of CC. Find below breakdown of CC and CH with their http response codes in

Re: [PATCH] ssl: factoring load cert/key and chains

2018-12-12 Thread Emmanuel Hocdet
Hi Julien, > Le 12 déc. 2018 à 14:28, Julien Laffaye a écrit : > > > On Wed, Dec 12, 2018 at 12:24 PM Emmanuel Hocdet > wrote: > > Hi, > > I tried to improve the haproxy loading time with a lot of certificates, and > see a double file > open for each certificate (one

[PATCH] REGTEST: level 1 health-check test 2.

2018-12-12 Thread Frederic Lecaille
Here is a new reg test for the health-check. Sounds similar to h1.vtc but is more intensive with client connections to verify there is no connection consumption by the health checks. Also checks that only servers with "check" option are "health-check'ed". Fred. From f4a26125601cadce735359

Re: [PATCH] ssl: factoring load cert/key and chains

2018-12-12 Thread Julien Laffaye
On Wed, Dec 12, 2018 at 12:24 PM Emmanuel Hocdet wrote: > > Hi, > > I tried to improve the haproxy loading time with a lot of certificates, > and see a double file > open for each certificate (one for private-key and one for the cert/chain). > Multi-cert loading part have not this issue and is go

Re: corruption of data with compression in 1.9-dev10

2018-12-12 Thread Willy Tarreau
On Wed, Dec 12, 2018 at 01:49:31PM +0100, Christopher Faulet wrote: > Le 12/12/2018 à 12:07, Pi Ba a écrit : > > Found the issue on the 10th (I think commit 56b0348).. so yesterday's > > commit isn't the (only) problem.. tested with commit 0007d0a the issue > > also happens. Reverting only below me

Re: corruption of data with compression in 1.9-dev10

2018-12-12 Thread Christopher Faulet
Le 12/12/2018 à 12:07, Pi Ba a écrit : Found the issue on the 10th (I think commit 56b0348).. so yesterday's commit isn't the (only) problem.. tested with commit 0007d0a the issue also happens. Reverting only below mentioned commit I can't easily do atm. I'll check more closely this evening.

[PATCH] ssl: factoring load cert/key and chains

2018-12-12 Thread Emmanuel Hocdet
Hi, I tried to improve the haproxy loading time with a lot of certificates, and see a double file open for each certificate (one for private-key and one for the cert/chain). Multi-cert loading part have not this issue and is good candidate for sharing code: patches is this work with factoring/c

Re: corruption of data with compression in 1.9-dev10

2018-12-12 Thread Pi Ba
Found the issue on the 10th (I think commit 56b0348).. so yesterday's commit isn't the (only) problem.. tested with commit 0007d0a the issue also happens. Reverting only below mentioned commit I can't easily do atm. I'll check more closely this evening. Op wo 12 dec. 2018 10:52 schreef Christopher

Re: corruption of data with compression in 1.9-dev10

2018-12-12 Thread Christopher Faulet
Le 12/12/2018 à 10:52, Christopher Faulet a écrit : Le 12/12/2018 à 02:08, PiBa-NL a écrit : Hi List, Didn't have time yet to bisect when it went wrong. But attached testfile produces the following output after 3 curl requests at different speeds, this seems to trigger a problem as the hash of

Re: corruption of data with compression in 1.9-dev10

2018-12-12 Thread Christopher Faulet
Le 12/12/2018 à 02:08, PiBa-NL a écrit : Hi List, Didn't have time yet to bisect when it went wrong. But attached testfile produces the following output after 3 curl requests at different speeds, this seems to trigger a problem as the hash of the downloaded content is nolonger the same as it sho