Re: HTTP/2 header issue: "Accept-Ranges" -> "Accept-Language"

Hi James, On Mon, 19 Nov 2018 at 19:29, James Brown wrote: > > Here's a strange thing I've noticed: > > When using HTTP/2, HAproxy is rewriting the "Accept-Ranges" response header > into "Accept-Language". Yup, exactly as you described, thanks for the report. I assume this is a bug in the

Re: HAProxy and Client Certificates for Admin site access

Hi Matt, On Sat, 3 Nov 2018 at 20:32, Matthew Sanders wrote: > I ran into a few work arounds to the problem, but I fear there is a few > performance considerations with these > approaches and felt there must be a more native way HAProxy could help with > this situation. > > In this blog post:

Re: CLI proxy for master process

Hello, On Fri, 26 Oct 2018 at 17:41, William Lallemand wrote: > Hi Aleks, > > With a nbproc setup, the first goal is to be able to access multiple stats > sockets from one socket. > > In a more "modern" nbthread setup, it's possible to have only one worker, but > we still fork a new process

Re: enabling H2 slows down my webapp, how to use keep-alive on backend ssl connection?

On Mon, 29 Oct 2018 at 23:55, Igor Cicimov wrote: > > > However when enabling H2 on the frontend the connection to the webserver > > > (which itself is also made with SSL encryption) is made for every single > > > requested object i suspect this is the main reason for the slowdown, it > > > now

Re: Lots of PR state failed connections with HTTP/2 on HAProxy 1.8.14

Hello James, On Wed, 24 Oct 2018 at 00:14, James Brown wrote: > > I tested enabling HTTP/2 on the frontend for some of our sites today and > immediately > started getting a flurry of failures. Browsers (at least Chrome) showed a lot > of SPDY > protocol errors and the HAProxy logs had a lot of

Re: HAproxy fails to start in CentOS with 'systemctl reload' ?

Hello, On Tue, 23 Oct 2018 at 02:25, Imam Toufique wrote: > > Hi Brain, > > That seems to have worked! Thanks!I did not know the wrapper was not > needed. Let's see if it dies again ( hopefully not ) . > > Thanks again! For the record: - you can find the systemd unit file, including a

Re: sample/fetch support for TLS extensions

Hello Alexey, On Tue, 16 Oct 2018 at 14:18, Alexey Elymanov wrote: > > I would like to propose a little patch, based on current ssl_capture > (ssl_sock.c) scheme. > Purpose is to be able to sample/fetch TLS extensions, it could be useful for > debugging or fingerprinting purposes (for

please ignore

just sending from a different email address to collect permanent auto-replies (as in "no longer works here")

Re: Seamless reload and servers connections status

Hi Sébastien, On Tue, 16 Oct 2018 at 09:45, Sébastien Kurtzemann wrote: > Our goal is to > - have some initial "free" servers in a tcp backend (for example 5 pods) > - when a connection start : one and only one "free" server handle it and it > become "busy" (we do this with maxconn=1) > - add

Re: Seamless reload and servers connections status

Hello Sébastien, On Mon, 15 Oct 2018 at 16:40, Sébastien Kurtzemann wrote: >> No. Only *restart* closes existing front and backend connections. >> Reload (both seamless and regular) closes them gracefully, so no >> request is lost. > > > Okay. I think I confound connections and servers

Re: Seamless reload and servers connections status

Hello, On Sat, 13 Oct 2018 at 10:34, Sébastien Kurtzemann wrote: > > Hi, > > I’ve got a question about haproxy "seamless reload" : when this > operation is perform does all backend servers connections be reset ? No. Only *restart* closes existing front and backend connections. Reload (both

Re: HAProxy "http-request auth" vs Safari WebSockets -- can this marriage be saved?

Hello Jeremy, On Thu, 11 Oct 2018 at 03:04, Jeremy Friesner wrote: > > [Error] WebSocket connection to 'wss://localhost:8080/' failed: > Invalid HTTP version string: HTTP/1.0 Sounds like it doesn't like the 401 response in HTTP/1.0. Can you try the attached patch (which upgrades 401

Re: Fix some warnings and a small bug in debug logic

Hello Dirkjan, On Sat, 6 Oct 2018 at 13:01, Dirkjan Bussink wrote: > > Hi all, > > On 14 Sep 2018, at 14:43, Dirkjan Bussink wrote: > > > While working on the OpenSSL 1.1.1 and TLS 1.3 cipher support issue, I also > > saw a number of compiler warnings that led me to investigate a bit. It > >

Re: TLS 1.3 options available with OpenSSL 1.1.1

On Sat, 6 Oct 2018 at 13:03, Dirkjan Bussink wrote: > > Hi Emeric, > > > On 24 Sep 2018, at 15:33, Emeric Brun wrote: > > > > Seems good for me except for documentation: > > > > Could you precise in the old "ciphers" description that this applies only > > for TLSv <= 1.2. (and add a ref to the

Re: Redirecting one https site to another

Hi Mark, On Thu, 4 Oct 2018 at 00:03, Mark Holmes wrote: > > Hi, > > > > I’m not sure if this is possible as haproxy isn’t terminating SSL in this > instance, > but I’d like to redirect https://urlone.co.uk to https://www.urlone.co.uk > [...] > Is what I am trying to achieve possible? Grateful

[PATCH] DOC: clarify force-private-cache is an option

"boolean" may confuse users into thinking they need to provide additional arguments, like false or true. This is a simple option like many others, so lets not confuse the users with internals. Also fixes an additional typo. Should be backported to 1.8 and 1.7. --- doc/configuration.txt | 4 ++--

Re: Problems setting up SMTP health checks with Sophos email gateway

Hello, On Thu, 27 Sep 2018 at 19:05, Gibson, Brian (IMS) wrote: > > EHLO domain.com\r\n > > Which throws an error “501 Syntactically invalid EHLO argument(s)” > > > > If I telnet to the host, and manually use EHLO domain.com it works fine, > but if I do EHLO domain.com\r\n it reproduces the

Re: h2 + text/event-stream: closed on both sides by FIN/ACK?

On Mon, 24 Sep 2018 at 16:36, Willy Tarreau wrote: > > On Mon, Sep 24, 2018 at 02:30:35PM +, Pierre Cheynier wrote: > > OK, I conclude this SSE pattern is not working out-of-the-box when using h2 > > as of > > now. Is it still true even if setting the user set the proper connection > >

Re: Problem with option tune.ssl.force-private-cache

Hello, On Mon, 24 Sep 2018 at 14:42, Maciej Małeta wrote: > > Hi, > > i have problem with my haproxy 1.8.14 > when i want start it, i get error: tune.ssl.force-private-cache' cannot > handle unexpected argument 'false' > in version 1.5 it's work fine > what is wrong in 'false' option? > I

Re: h2 + text/event-stream: closed on both sides by FIN/ACK?

Hello, On Fri, 21 Sep 2018 at 15:45, Pierre Cheynier wrote: > Let me know if you see something obvious here, or if this is candidate to a > bug. > > We have a service using SSE through text/event-stream content-type. > > In HTTP/1.1 we have a normal stream as expected : > < HTTP/1.1 200 OK > <

Re: Intermittent HTTP 503 Error (Service Unavailable) with about 250 Connections

Hello, On Wednesday, 19 September 2018, Shishir Kumar Yadav < shis...@purestorage.com> wrote: > I am able to get logs and I see these errors - > > 2018-09-18 23:39:22+00:00 127.0.0.1 haproxy[569]: Connect() failed for > backend ir-http-server-backend: no free ports. > Make sure you enable

Re: [ANNOUNCE] haproxy-1.9-dev2

Hi Manu, On Fri, 14 Sep 2018 at 15:45, Emmanuel Hocdet wrote: > > Hi, > > Quick test with 1.9-dev2, and i see latency (in seconds) to connect to > haproxy with SSL (tcp mode). > It’s ok in master with 9f9b0c6a. > No time to investigate more for the moment. I cannot reproduce it in a simple

Re: Intermittent HTTP 503 Error (Service Unavailable) with about 250 Connections

Hello, On Tue, 18 Sep 2018 at 02:36, Shishir Kumar Yadav wrote: > > Hi All, > > I am using haproxy 1.8.3 Which has 169 unfixed bugs: http://www.haproxy.org/bugs/bugs-1.8.3.html I'd strongly suggest you use latest stable, although that doesn't mean it has something to do with your specific

Re: TLS 1.3 options available with OpenSSL 1.1.1

Hello Dirkjan, On Thu, 13 Sep 2018 at 16:44, Dirkjan Bussink wrote: > So with a new API call, does that mean adding for example a `ciphersuites` > option that works similar to `ciphers` today that it accepts a string and then > calls `SSL_CTX_set_ciphersuites`? Yes, that's what I'd have in

Re: TLS 1.3 options available with OpenSSL 1.1.1

Hi Dirkjan, On Thu, 13 Sep 2018 at 15:35, Dirkjan Bussink wrote: > > Hi all, > > With the release of OpenSSL 1.1.1, TLS 1.3 is now also available. It already > is working fine in my testing with HAProxy 1.8, there is however one issue. > Currently there is no way to control the ciphers for

Re: Hang in haproxy 1.8.13

On Tue, 11 Sep 2018 at 11:55, David King wrote: > > Apologies, i forgot to mention this is running on FreeBSD 11.1 > > I've just run the same tests on Centos and there is no issue Could you retry with the current development tree (1.9) from git? There are a number of fixes waiting to be

Re: ppa1~xenial with TLS v1.3 support

Hello, On Wed, 5 Sep 2018 at 11:31, Haim Ari wrote: > > Hello, > > Is there a way to add TLS v1.3 without compiling haproxy ? (and still use PPA > version for Ubuntu) No. TLSv1.3 requires OpenSSL 1.1.1, which is still in beta phase, and even if it becomes stable, it will require some time

Re: [PATCH] BUG/MEDIUM: ECC cert should work with TLS < v1.2 and openssl >= 1.1.1

Hello Mano, On Mon, 3 Sep 2018 at 18:26, Emmanuel Hocdet wrote: > > Hi Lukas, Emeric > > This patch fix the issue. If you can check it. I confirm the patch fixes the original test case and also works fine in my Chrome on XP testbed (TLSv1.2, no ECC support). As you mentioned for clients using

Re: H2: interoperability issue due to lack of CONTINUATION frame support

Hello, On Sun, 2 Sep 2018 at 17:24, Willy Tarreau wrote: > > Hi Lukas, > > On Sun, Sep 02, 2018 at 11:55:29AM +0200, Lukas Tribus wrote: > > Ok. I think with OpenSSL 1.1.1 we may be able to configure ALPN > > differently for RSA vs ECC certificates (of the same hostname)

Re: BUG: ssl: regression with openssl 1.1.1 when using <= TLSv1.2

Hello, On Sat, 1 Sep 2018 at 20:49, Lukas Tribus wrote: > > I've confirmed the change in behavior only happens with an ECC > > certificate, an RSA certificate is not affected. > > Just to confirm that this is still an actual problem with current > haproxy and openssl 1.

Re: H2: interoperability issue due to lack of CONTINUATION frame support

Hello Willy, On Sat, 1 Sep 2018 at 21:00, Willy Tarreau wrote: > I wanted to address it but the CONTINUATION frame is the worst design > mistake of the H2 protocol and results in layering violations which > make it particularly problematic to implement. In short, while all > frames are

Re: Force response to send HTTP/2 GOAWAY?

Hello Joseph, On Sun, 2 Sep 2018 at 03:42, Joseph Sible wrote: > > When using HTTP/2, is there a way to force haproxy to send a GOAWAY > frame after a given response? I expected that "option forceclose" > might do this, but I tested it and it doesn't seem to. My use-case for > this is having a

Re: BUG: ssl: regression with openssl 1.1.1 when using <= TLSv1.2

Hello Emeric, On Wed, 30 May 2018 at 19:34, Lukas Tribus wrote: > >> Do you have any specific parameter related to ssl in your global section? > > I've confirmed the change in behavior only happens with an ECC > certificate, an RSA certificate is not affected

H2: interoperability issue due to lack of CONTINUATION frame support

Hi Willy, haproxy is currently unable to handle CONTINUATION [1] frames (see commit 61290ec77 - [2]). If a client emits a CONTINUATION frame, we will break the connection and send GOAWAY due to INTERNAL_ERROR. This of course leads to interoperability issues. Notably, older Chrome/Chromium

Re: Issue with TCP splicing

Hello Julien, On Thu, 23 Aug 2018 at 20:49, Julien Semaan wrote: > > Hi Olivier, > > Sorry for the delay, obtaining the core dump from a production environment > was a bit tricky. > > So, I have attached the core dump to this email. I hope this will help you > identify the issue. The

[PATCH] DOC: dns: explain set server ... fqdn requires resolver

Abhishek Gupta reported on discourse that set server [...] fqdn always fails. Further investigation showed that this requires the internal DNS resolver to be configured. Add this requirement to the docs. Must be backported to 1.8. --- doc/management.txt | 3 ++- 1 file changed, 2 insertions(+),

Haproxy 1.8 segfaults on misconfigured set server fqdn command

Hello, the "set server / fqdn " admin socket command requires the internal DNS resolver to be configured and enabled for that specific server. This is undocumented, and I will provide a doc fix soon. However, when the resolver is not configured, and when haproxy is compiled with thread

Re: haproxy and changing ELB IPs

Hello, > We recently had an outage for short time related to NameServer's h/w failure > (both primary and secondary went down). > We were told that it is possible for these IPs to change in the future. It > never happened so far though. So you don't have changing nameservers at all, but it is

Re: haproxy and changing ELB IPs

On Sat, 4 Aug 2018 at 14:21, Igor Cicimov wrote: > > Hi, > > On Sat, Aug 4, 2018 at 1:50 AM, K3 wrote: >> >> Hi, >> We are running into a problem and would like to hear any advice. >> >> Our Setup: >> We use haproxy 1.7.7 with two backends. >> One of the backends is AWS ELB >> The haproxy is

Re: SNI matching issue when hostname ends with trailing dot

Hello Warren, On Tue, 22 May 2018 at 15:48, Warren Rohner wrote: > The other day I inadvertently appended a trailing dot to the hostname > for one of our sites (e.g. https://www.example.com.), and when I did > this HAProxy returned the default cert to the browser rather than the > expected cert

Re: Help with backend server sni setup

On Mon, 30 Jul 2018 at 13:30, Aleksandar Lazic wrote: > > Hi. > > I have the following Setup. > > APP -> Internal Haproxy -(HTTPS)-> external HAProxy -> APP > > The external HAProxy is configured with multiple TLS Vhost. Never use SNI for Vhosting. It should work with the host header only. SNI

Re: Building HAProxy 1.8 fails on Solaris

Hello, On Fri, 20 Jul 2018 at 15:58, Olivier Houchard wrote: > > Hi LuKas, > > On Fri, Jul 20, 2018 at 01:53:35PM +0200, Lukas Tribus wrote: > > Hello Oliver, > > > > On Fri, 20 Jul 2018 at 11:55, Olivier Houchard > > wrote: > > > > > > Hi

Re: Building HAProxy 1.8 fails on Solaris

Hello Oliver, On Fri, 20 Jul 2018 at 11:55, Olivier Houchard wrote: > > Hi, > > On Fri, Jul 20, 2018 at 12:22:20AM +, Thrawn wrote: > > So...is there a way to adapt this patch so it won't cause random SSL errors and is suitable to apply to the trunk? We don't really want to run a customised

Re: [PATCH] MEDIUM: proxy_protocol: Send IPv4 addresses when possible

Hello, On Wed, 18 Jul 2018 at 14:30, Willy Tarreau wrote: > > Hi Tim, > > On Wed, Jul 18, 2018 at 01:48:01PM +0200, Tim Düsterhus wrote: > > This would solve the issue for my use case and should not break anything > > (a few UNKNOWNs will become TCP6 then). > > OK. > > > I can rework the patch,

Re: [PATCH] MEDIUM: proxy_protocol: Send IPv4 addresses when possible

Hello Tim, On Fri, 29 Jun 2018 at 21:00, Tim Duesterhus wrote: > > This patch changes the sending side of proxy protocol to convert IP > addresses to IPv4 when possible (and converts them IPv6 otherwise). > > Previously the code failed to properly provide information under > certain

Re: Building HAProxy 1.8 fails on Solaris

On Tue, 17 Jul 2018 at 01:09, Thrawn wrote: > > Ah, indeed, the GCC version provided on our server is 3.4.3. But the readme > on https://github.com/haproxy/haproxy says "GCC between 2.95 and 4.8". Can > the build be changed to continue supporting older GCC, or do the docs need an > update?

Re: TLS handshake works with certificate name mismatch using "verify required" and "verifyhost"

On Mon, 16 Jul 2018 at 11:57, Martin RADEL wrote: > > Hi, > > I think we found the issue: > Seems that there was a misunderstanding from us regarding the haproxy > documentation with the "verifyhost" option. > > If I get it right, the documentation says that if we have a haproxy config > that >

Re: Bug when passing variable to mapping function

Hello, On Fri, 29 Jun 2018 at 07:15, Jarno Huuskonen wrote: > > Hi, > > On Thu, Jun 28, Jarno Huuskonen wrote: > > I think this is the commit that breaks map_regm in this case: > > b5997f740b21ebb197e10a0f2fe9dc13163e1772 (MAJOR: threads/map: Make > > acls/maps thread safe). > > > > If I

Re: Building HAProxy 1.8 fails on Solaris

Hello, On Mon, 16 Jul 2018 at 03:12, Thrawn wrote: > > Update: If I disable threading with > > USE_THREAD= > > then the build gets much further, but still fails eventually with: > > gcc -g -o haproxy src/ev_poll.o ebtree/ebtree.o ebtree/eb32sctree.o > ebtree/eb32tree.o ebtree/eb64tree.o

Re: TLS handshake works with certificate name mismatch using "verify required" and "verifyhost"

Hello Martin, > we have a strange situation with our HAProxy, running on Version 1.8.8 with > OpenSSL. Please share the output of haproxy -vv. Did you build openssl yourself or is this a distribution provided openssl lib? I am asking because build issues can lead to very strange behavior. >

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

Hey guys, FYI after lots of discussions with openssl folks: https://github.com/openssl/openssl/issues/5330 https://github.com/openssl/openssl/pull/6388 https://github.com/openssl/openssl/pull/6432 OpenSSL 1.1.1 will now keep the FD open by default:

Re: HAProxy 1.8 built with rpath'd openssl links ok; but `haproxy -vv` reports "Built with" and "Running on" conflict

On Sat, 23 Jun 2018 at 11:35, PGNet Dev wrote: > > > Sure. Your attitude and threats are not helpful in this conversation though. > > Threats? WTF are you talking about? Talking about: > I'll have to decide whether I'm more interested in haproxy, or a consistently > 'modern/current' openssl

Re: HAProxy 1.8 built with rpath'd openssl links ok; but `haproxy -vv` reports "Built with" and "Running on" conflict

>> it's complicated to keep everything clean but any help is welcomed. > > Step 1 has been simply to understand the problem. Sure. Your attitude and threats are not helpful in this conversation though. > What I'm suggesting is that there's a possibility -- as per my other > post, still unclear

Re: HAProxy 1.8 built with rpath'd openssl links ok; but `haproxy -vv` reports "Built with" and "Running on" conflict

Hello, right, your (second) build issue is caused by the --api=1.1.0 configuration, removing old interfaces. Drop it from your openssl configuration, and it will work fine. > particularly with tls1.3-capable openssl 1.1.1 "ComingSoon(tm)", might be > worth a review Haproxy 1.8 and -dev works

Re: HAProxy 1.8 built with rpath'd openssl links ok; but `haproxy -vv` reports "Built with" and "Running on" conflict

Hello, On Fri, 22 Jun 2018 at 22:09, PGNet Dev wrote: > > - share the openssl config line and installation commands > > gcc --version > gcc (SUSE Linux) 8.1.1 20180614 [gcc-8-branch revision 261584] > which openssl > /usr/local/openssl11/bin/openssl > openssl version >

Re: HAProxy 1.8 built with rpath'd openssl links ok; but `haproxy -vv` reports "Built with" and "Running on" conflict

Hello, On Fri, 22 Jun 2018 at 20:45, PGNet Dev wrote: > with 'your' advised "actual paths", and from Makefile > > # OpenSSL is packaged in various forms and with various dependencies. > # In general -lssl is enough, but on some platforms, -lcrypto may be > needed, > #

Re: HAProxy 1.8 built with rpath'd openssl links ok; but `haproxy -vv` reports "Built with" and "Running on" conflict

Hello, > make V=1 \ > TARGET=linux2628 \ > USE_SYSTEMD=1 \ > USE_OPENSSL=1 \ > SSL_INC=" -I/usr/local/openssl11/include" \ > SSL_LIB=" -L/usr/local/openssl11/lib64 > -Wl,-rpath,/usr/local/openssl11/lib64" \ > ADDLIB="-ldl -lssl

Re: srv_is_up : unable to find server.

On 5 June 2018 at 13:18, Brent Clark wrote: > Good day Guys > > I am at a total loss, and Im hoping someone on this list, would be so kind > to review my setup. > > I am trying to get haproxy to monitor redis / sentinel. But I keep getting. > > [WARNING] 155/110602 (309) : config : log format

Re: Truly seamless reloads

Hello Veiko, On 1 June 2018 at 13:13, Veiko Kukk wrote: > On 31/05/18 23:15, William Lallemand wrote: >> >> Sorry but unfortunately we are not backporting features in stable >> branches, >> those are only meant for maintenance. >> >> People who want to use the seamless reload should migrate to

Re: BUG: ssl: regression with openssl 1.1.1 when using <= TLSv1.2

Hello, On 22 May 2018 at 15:26, Lukas Tribus wrote: > Hello Emeric, > > > On 22 May 2018 at 14:44, Emeric Brun wrote: >> Hi Lukas, >> >> I've just made some tests using openssl-1.1.1-pre6 and can't reproduce the >> issue. >> >> here my simple co

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

Hi Emeric, On 24 May 2018 at 11:19, Emeric Brun wrote: > in pre6 there is a news wrapping function on getrandom which have different > fallback way to use the syscall. > > Perhaps the openssl -r output depends of that (if getrandom was found from > glibc or if a syscall

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

Hello, On 23 May 2018 at 22:17, Jim Freeman wrote: > Or kludge around it with eg; http://www.issihosts.com/haveged/ ? No, it's not about insufficient entropy in the kernel. It's about interfacing with that entropy while in chroot. Lukas

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

Hello, On 23 May 2018 at 18:29, Emeric Brun wrote: > This issue was due to openssl-1.1.1 which re-seed after an elapsed time or > number of request. > > If /dev/urandom is used as seeding source when haproxy is chrooted it fails > to re-open /dev/urandom > > By defaut

Re: [RFC PATCH] MINOR: ssl: set SSL_OP_PRIORITIZE_CHACHA

Hi Willy, On 22 May 2018 at 18:54, Willy Tarreau wrote: > On Tue, May 22, 2018 at 04:28:38PM +0200, Emeric Brun wrote: >> I agree, we could merge it as it is. > > OK thanks Emeric. > > So Lukas, just let me know if you want me to merge it as-is or if you > still have some polishing

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

Hello, On 23 May 2018 at 13:10, Sander Hoentjen wrote: > I can confirm the issue is gone when I don't use chroot. I will try to > see if I can get more info like a strace soon. I won't be able to today > though. Thanks Lucas and Emeric! 1.8.9 with 1.1.1-pre6 chrooted is now

Re: BUG: ssl: regression with openssl 1.1.1 when using <= TLSv1.2

Hello Emeric, On 22 May 2018 at 14:44, Emeric Brun wrote: > Hi Lukas, > > I've just made some tests using openssl-1.1.1-pre6 and can't reproduce the > issue. > > here my simple configuration: > frontend my > mode http > bind :443 ssl crt default strict-sni >

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

Hello, On 22 May 2018 at 11:48, Sander Hoentjen wrote: > I did, but I still experience the same issues. What is your exact > haproxy version you tested with? Mine is 1.8.8 > Built with OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018 > Running on OpenSSL version :

BUG: ssl: regression with openssl 1.1.1 when using <= TLSv1.2

Hey guys, we have a regression in 1.8 and -dev with OpenSSL 1.1.1 (from the first beta to current master): when strict-sni is set, TLSv1.0 and TLSv1.1 does not work (TLSv1.2 is fine). I haven't tested whether SNI based certificate selection is broken as well, but strict-sni definitely rejects

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

Hello, On 19 April 2018 at 11:09, Sander Hoentjen wrote: > I just tried 1.1.1-pre5, and I still have the same issue. I'm running 1.1.1-pre6 now with good results. You may want to check that out. cheers, lukas

[RFC PATCH] MINOR: ssl: set SSL_OP_PRIORITIZE_CHACHA

Sets OpenSSL 1.1.1's SSL_OP_PRIORITIZE_CHACHA unconditionally, as per [1]: When SSL_OP_CIPHER_SERVER_PREFERENCE is set, temporarily reprioritize ChaCha20-Poly1305 ciphers to the top of the server cipher list if a ChaCha20-Poly1305 cipher is at the top of the client cipher list. This helps those

Re: HAProxy Healthcheck issue using Virtual hostname

Hello Igor, Sen, On 4 May 2018 at 08:46, Igor Cicimov wrote: > Have you tried: > > option httpchk GET /env HTTP/1.1\r\nHost:\ %[req.hdr(Host)] When you are health checking, you don't have a Host header as you don't have a frontend connection associated to it.

Re: Use SNI with healthchecks

Hello Willy, On 25 April 2018 at 12:16, Willy Tarreau wrote: >> I'm not even sure that differentiate "Host" header from SNI values is >> possible on softwares like Nginx or Apache. > > It should not, that would be a violation of HTTP over TLS. I think I disagree. This is very

Re: Persisting stick tables on reload on 1.8

Hello Christian, On 26 April 2018 at 09:45, Christian Greger wrote: > Hi, > > I was hoping the seamless reload in 1.8 would retain stick tables, but I'm > having no luck. Is it possible? > Stick tables can be transferred from the old to the new process while reloading by

Re: Backup server takes too long to go active

Hello Shawn, On 25 April 2018 at 03:55, Shawn Heisey wrote: > I'm hoping to figure out how to make a backup server transition immediately > to active as soon as the primary server is marked down. If you need > additional info, please let me know. Like I said in the other

Re: Use SNI with healthchecks

Hello Vincent, On 23 April 2018 at 16:38, GALLISSOT VINCENT wrote: > Does anybody know how can I use healthchecks over HTTPS with SNI support ? You need haproxy 1.8 for this, it contains the check-sni directive which allows to set SNI to a specific string for the

Re: multithreading issuse in haproxy 1.8.5

Hello, On 19 April 2018 at 14:31, Slawa Olhovchenkov wrote: >> This is very useful, thank you. I'm seeing overall that when you're on >> 1.7.10+kqueue and 1.8.5+poll the overall %user is the same. However >> it's the system which makes a huge difference there (to be expected >>

Re: Version 1.5.12, getting 502 when server check fails, but server is still working

Hello Shawn, On 17 April 2018 at 15:24, Shawn Heisey wrote: >>> I described that issue in a separate message to the >>> list. I do have a workaround to that issue -- I'm no longer using >>> "backup" on any server entries for this service. >> >> Then I don't see how it

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

Hello Sander, On 16 April 2018 at 10:55, Sander Hoentjen wrote: > Reading my email again it looks like somehow I messed up part of it, > retrying: > > Hi all, > > I built Haproxy (1.8.7) against openssl 1.1.1-pre4, and now after 1 hour > running haproxy stops accepting new

Re: Version 1.5.12, getting 502 when server check fails, but server is still working

Hello Shawn, On 16 April 2018 at 17:39, Shawn Heisey wrote: > I enabled the admin socket so that I could renew OCSP stapling. As far as I > understand, it can only be used on the load balancer machine itself, and I > think this is the only way to renew stapling other than

Re: Version 1.5.12, getting 502 when server check fails, but server is still working

Hello Shawn, please keep the mailing-list in the loop. On 16 April 2018 at 16:53, Shawn Heisey wrote: >> Having said that, you'd be better off setting the server to >> maintenance mode instead of letting the health check fail (via >> webinterface or stats socket): >>

Re: Version 1.5.12, getting 502 when server check fails, but server is still working

Hello, On 15 April 2018 at 21:53, Shawn Heisey wrote: > I'm working on making my application capable of handling service restarts on > the back end with zero loss or interruption. It runs on two servers behind > haproxy. > > At application shutdown, I'm setting a flag

Re: resolvers - resolv.conf fallback

Hello Willy, On 6 April 2018 at 14:14, Willy Tarreau wrote: >> The confusion often arises because haproxy accepts a resolver >> configuration where no resolvers are configured. Maybe we should >> reject the configuration when a resolver is referred to in the servers >> lines, but

Re: resolvers - resolv.conf fallback

Hi Willy, On 6 April 2018 at 11:14, Willy Tarreau wrote: >> I don't think we need a new config know. > > Just thinking, is the goal *not to have to* configure "resolve" on > server lines in this case, or to avoid having to pre-configure the > resolvers themselves when they're the

Re: resolvers - resolv.conf fallback

Hello Baptiste, > - (for Lukas) what do you think is better, a configuration option to trigger > parsing of resolv.conf or as proposed, if no nameserver are found, we use > resolv.conf as a failback? I don't think we need a config knob for this; currently we don't do anything when no

Re: Warning: upgrading to openssl master+ enable_tls1_3 (coming v1.1.1) could break handshakes for all protocol versions .

Hello Emeric, On 12 January 2018 at 15:57, Emeric Brun wrote: > Hi All, > > FYI: upgrading to next openssl-1.1.1 could break your prod if you're using a > forced cipher list because > handshake will fail regardless the tls protocol version if you don't specify > a cipher

Re: transparent mode -> chksum incorrect

Hello, On 22 March 2018 at 11:49, matei marius wrote: > When I try to access the service from the same IP class with haproxy I see > the packets having incorrect checksum. This is most likely due to offloading techniques such as TX checksumming, where tcpdump will not see

Re: Feature suggestion: Check for same binding on multiple frontends

Hello, On 8 March 2018 at 06:36, Moomjian, Chad wrote: > Thanks for the information, Lukas. I'm confused why this is not a default > option though. Can you think of a time when you would ever want the exact > same binding in multiple places in the config? noreuseport

Re: Feature suggestion: Check for same binding on multiple frontends

Hello Chad, On 7 March 2018 at 03:34, Moomjian, Chad wrote: > Haproxy Developers, > > > > I recently modified a configuration file for haproxy, and after setting it > up, I noticed that about half of my requests came back with a 503 error, and > the other half came back

Re: haproxy 1.8.4-1 hangs on kernel 4.16.0-041600rc1

Hello, On 6 March 2018 at 11:38, Adrian Veith wrote: > I had this hang in haproxy after trying out kernel 4.16.0-041600rc1 > after starting haproxy for some minutes. Now I am back on kernel > 4.15.0-10-generic and everything seems ok so far. Yeah, this is a kernel bug, you need

Re: Problem with linux 4.14.22 and haproxy 1.7.10

Hello Richard, On 2 March 2018 at 19:37, Richard Lee wrote: > > We recently updated our linux kernel from 4.14.19 to 4.14.22, and now haproxy > hangs forever in a system call: > > $ ps -lfC haproxy > F S UIDPID PPID C PRI NI ADDR SZ WCHAN STIME TTY

Re: TLS termination with 2 certs on same IP

Hello Dave, On 2 March 2018 at 01:09, Dave Cottlehuber wrote: > I have 2 TLS cert bundles that I'd like to serve off haproxy, using a single > IP. Both certs have multiple SANs in them. > > - our main production site: api,beta,www.example.com using EV cert > - a

Re: Haproxy for Solaris

Responded on discourse: https://discourse.haproxy.org/t/haproxy-installation-for-an-solaris/2167

Re: BUG/MINOR: dns: false positive downgrade of accepted_payload_size

Hello Baptiste, On 21 February 2018 at 19:59, Lukas Tribus <lu...@ltri.eu> wrote: > Baptiste, I don't think you'd find the symptoms I have in mind > acceptable on a load-balancer, so there has to be a misunderstanding > here. I would like to do some tests, maybe I can come u

Re: BUG/MINOR: dns: false positive downgrade of accepted_payload_size

Hello Baptiste, I'm sorry if my comments are blunt, but I think this discussion is important and I do not want my messages to be ambiguous. I do appreciate all the work you are doing in the DNS subsystem. On 21 February 2018 at 18:05, Baptiste wrote: >> However in Haproxy

Re: Haproxy 1.8.4 400's with http/2

Hello Sander, make sure you use "option http-keep-alive" as http mode, specifically httpclose will cause issue with H2. If that's not it, please share the configuration; also you may want to try enabling proxy_ignore_client_abort in the nginx backend [1]. cheers, lukas [1]

Re: BUG/MINOR: dns: false positive downgrade of accepted_payload_size

Hello Baptiste, On 21 February 2018 at 08:45, Baptiste wrote: >> Is this downgrade at good thing in the first place? Doesn't it hide >> configuration and network issues, make troubleshooting more complex >> and the haproxy behavior less predictable? > > > It is an rfc

Re: BUG/MINOR: dns: false positive downgrade of accepted_payload_size

Hello Baptiste, On 19 February 2018 at 18:59, Baptiste wrote: > Hi guys, > > While working with consul, I discovered a "false positive" corner case which > triggers a downgrade of the accepted_payload_size. Is this downgrade at good thing in the first place? Doesn't it hide

Re: Fix building without NPN support

Hello, On 18 February 2018 at 09:58, Dmitry Sivachenko wrote: > >> On 15 Feb 2018, at 17:58, Bernard Spil wrote: >> Hi Lukas, >> >> Agree. Updated patch attached. >> >> Bernard. > > > Is this patch good, Lukas? > Any plans to integrate it? Just two

Re: Fix building without NPN support

Hello, On 15 February 2018 at 13:42, Bernard Spil wrote: > Hello HAProxy maintainers, > > https://github.com/Sp1l/haproxy/tree/20180215-fix-no-NPN > > Fix build with OpenSSL without NPN capability > > OpenSSL can be built without NEXTPROTONEG support by passing > -no-npn to

Re: Why is there a tilde ~ character behind the frontend name in the log file?

Hi Pieter, On 7 February 2018 at 11:15, Pieter Vogelaar wrote: > I have a http frontend “default-http” and “default-https”. In the access log > is the ~ (tilde) character appended to the default-https frontend name, like > “default-https~”. > > > Why is that? As per:

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