Re: haproxy 1.8 seems to be using wrong backend

[Christian Bönning]

Good Morning Lukas,

Thank you!

This was indeed the change which was necessary.
Removed the ssl_fc_sni part in my ACLs, reactivated h2 and I’m back on track.

Cheers (from a happy http2 user),
Chris



> Am 11.12.2017 um 23:48 schrieb Lukas Tribus :
> 
> Hell Chris,
> 
> 
> 2017-12-11 20:04 GMT+01:00 Christian Bönning 
> :
>> Hi,
>> 
>> I recently switched from nginx to haproxy 1.8 for SSL termination and load 
>> balancing in front of my application but saw an odd behaviour with "alpn 
>> h2,http/1.1" enabled on my frontend.
>> 
>> I'm running a single haproxy instance in front of my applications switching 
>> between them based on "ssl_fc_sni" or HTTP host.
>> [...]
>> use_backend backend_app_jira if { ssl_fc_sni -i jira.example.com || 
>> hdr(host) -i jira.example.com }
>> use_backend backend_app_confluence if { ssl_fc_sni -i confluence.example.com 
>> || hdr(host) -i confluence.example.com }
> 
> That's whats wrong. You can't route based on ssl_fc_sni or HTTP Host.
> This will lead to the this exact behavior.
> 
> You have to route based on HTTP Host header *only*. The SNI value will
> be "jira.example.com" for the entire H2 (or H1) session, even when you
> request something on confluence - that is if your certificate handles
> both domains. SNI is for certificate selection only, you need to look
> at host header (*only*), for deciding with backend to choose for a
> specific HTTP transaction.
> 
> 
> The difference between h2 and http/1.1 is that h2 keeps the SSL
> session alive for a longer time (timeout server or timeout client)
> than http/1.1 (timeout http-keep-alive). You browser may also not
> reuse the SSL session for a different domain in http/1.1, while it
> does soin h2. So that's why you may see different behavior in h2,
> depending on your browser.
> 
> 
> 
> Regards,
> Lukas

Re[3]: Use haproxy 1.8.x to balance web applications only reachable through Internet proxy

[Aleksandar Lazic]

Hi

There is a simpler solution with delegate.

I have run a squid on localhost 127.0.0.1:3128

I have run delegate with PROXY module

delegate9.9.13$ src/delegated -f -vv -P127.0.0.1:8081 
PROXY=127.0.0.1:3128


and now the swiss army knife curl was the haproxy simulator.

echo 'GET http://www.php.net/' |curl -v telnet://127.0.0.1:8081

Squid Log:

tail -f /var/log/squid/access.log
1513036938.918 51 127.0.0.1 TCP_MISS/200 30908 GET http://www.php.net/ - 
HIER_DIRECT/82.100.240.32 text/html


delegate log:

###
12/12 01:02:18.87 [26188] 1+1: ConnectToServer connected [19] 
{127.0.0.1:3128 <- 127.0.0.1:38250} [0.000s]

12/12 01:02:18.87 [26188] 1+1: willSTLS_SV[http]: ServerFlags=0 1EAC00E0
12/12 01:02:18.87 [26188] 1+1: HTTP => (www.php.net:80) GET /^M
12/12 01:02:18.87 [26184] 1+0: AcceptByMain: start polling(15000)[11]...
12/12 01:02:18.87 [26188] 1+1: KeepAlive[19] = 1
12/12 01:02:18.87 [26188] 1+1: #PROXY REQUEST = GET http://www.php.net/ 
HTTP/0.9^M

###

I know that the last version is from 2014 but I don't know any other 
tool which can handle the tcp to http proxy task.


Regards
aleks

-- Originalnachricht --
Von: "Aleksandar Lazic" 
An: "Moemen MHEDHBI" ; "Gbg" ; 
haproxy@formilux.org

Gesendet: 11.12.2017 20:11:48
Betreff: Re[2]: Use haproxy 1.8.x to balance web applications only 
reachable through Internet proxy



Hi.

-- Originalnachricht --
Von: "Moemen MHEDHBI" 
An: "Gbg" ; haproxy@formilux.org
Gesendet: 11.12.2017 18:45:16
Betreff: Re: Use haproxy 1.8.x to balance web applications only 
reachable through Internet proxy



On 11/12/2017 17:21, Gbg wrote:

Hello  Moemen,

unless I got this wrong this isn't the setup I search for. I 
don't  need haproxy to *be* a proxy but rather *use* a proxy 
while  serving content over http as a reverse proxy


Perhaps I should have given the thread this name


  I get your point, HAProxy does not support using a "http/socks
proxy".
  HAProxy intends to be "an HTTP reverse-proxy" retrieving resources   
 from backend servers and the requests sent to a server are different  
  from the ones sent to a "forward proxy".
  That being said HAProxy  can still "pass" proxy requests to
http/socks proxies if the client is configured to use a proxy.
How about to use delegate ( http://delegate.org/documents/ ) for this, 
just as an idea.


haproxy -> delegate FORWARD=... CONNECT=proxy:

http://delegate.org/delegate/Manual.shtml?FORWARD
http://delegate.org/delegate/Manual.shtml?CONNECT

I know it's not that elegant but it could work.



  ++


Am 11. Dezember 2017 16:56:12 MEZ schriebMoemen MHEDHBI 
 :

On 11/12/2017 15:02, Gbg wrote:


I need to contact applications through a socks or http proxy.

My current setup looks like this but only works when the Computer
haproxy runs on has direct Internet connection (which is not the 
case

in our datacenter, I tried this at home)

frontend main
bind *:8000
acl is_extweb1 path_beg -i /policies
acl is_extweb2 path_beg -i /produkte
use_backend externalweb1 if is_extweb1
use_backend externalweb2 if is_extweb2

backend externalweb1
server static www.google.com:80 check

backend externalweb2
server static www.gmx.net:80 check

There is an SO post which addresses the same question and provides
some more details:
https://stackoverflow.com/questions/47605766/use-haproxy-as-an-reverse-proxy-with-an-application-behind-internet-proxy





Hi Gbg,

For this to work you need the client (browser for example) to be 
aware

of the forward proxy.
So first you need to configure the client to use HAProxy as a 
forward
proxy, then in the HAProxy conf you need to use the forward proxy in 
the

backend and the configuration may look like this:

frontend main
bind *:8000
acl is_extweb path_beg -i /policies /produkte
use_backend forward_proxy if is_extweb
default_backend another_backend

backend forward_proxy
 server static < IP-of-the-forward-proxy > : < Port > check


++

Moemen MHEDHBI






--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail  
gesendet.


--
Moemen MHEDHBI

Re: Testing master-worker reloads on HAProxy 1.8

[Anthony Via]

> > > Did you try launching a new haproxy process with the -sf option, without
> > > using the master-worker?
> >
> > Yes, and that also failed with the same "cannot bind" error.

> Without "expose-fd listeners" I suppose?

That is correct.

> Okay, so it looks like that the unbinding with SIGTOUT does not work on your
OS, but the seamless reload seems to work...

> According to the code commentary that's a known problem on Solaris, maybe we
should add a note in the documentation about it.

Good to know. Thanks for looking into this.

Anthony


From: William Lallemand 
Sent: Monday, December 11, 2017 3:32 PM
To: Anthony Via
Cc: haproxy@formilux.org
Subject: Re: Testing master-worker reloads on HAProxy 1.8

On Mon, Dec 11, 2017 at 11:03:52PM +, Anthony Via wrote:
> > Did you try the seamless reload using -x without the master-worker?
>
> I was looking into the "-x" option and it looks like simply adding "expose-fd
> listeners" to my stats socket has fixed this issue for me. Sending SIGUSR2 to
> the master process now works as expected. Is that option required for this
> reload model?

"expose-fd listeners" is the option which give the ability to the admin socket
to pass the listeners FDs, so this option is mandatory if you want to use the
seamless reload.

When you use the 'normal' daemon model, you have to specify -x with the path of
the socket where you want to retrieve the listeners.

Using the master-worker you only need to specify "expose-fd listeners" in the
config, and the master will use this socket and reexecute itself with the right
"-x" option.

> > Did you try launching a new haproxy process with the -sf option, without
> > using the master-worker?
>
> Yes, and that also failed with the same "cannot bind" error.

Without "expose-fd listeners" I suppose?

> > What is your operating system and version exactly?
>
> We are using SmartOS:
> # uname -a
> SunOS ops-dev-lb03 5.11 joyent_20170315T185612Z i86pc i386 i86pc Solaris
>
> > I think the old processes did not receive the SIGTTOU for an unknown
> > reason, or did not unbind once it received the signal.
>
> > Maybe you could try to compare what's happening on your solaris-like system
> > and your ubuntu with the -dR option, using strace on linux and truss on
> > solaris.
>
> I verified using dtrace that the worker is indeed receiving the SIGTTOU
> signal from the master (200 times), so the worker must not have been
> unbinding.
>

Okay, so it looks like that the unbinding with SIGTOUT does not work on your
OS, but the seamless reload seems to work...

According to the code commentary that's a known problem on Solaris, maybe we
should add a note in the documentation about it.

Regards,

--
William Lallemand

Re: Testing master-worker reloads on HAProxy 1.8

[William Lallemand]

On Mon, Dec 11, 2017 at 11:03:52PM +, Anthony Via wrote:
> > Did you try the seamless reload using -x without the master-worker?
> 
> I was looking into the "-x" option and it looks like simply adding "expose-fd
> listeners" to my stats socket has fixed this issue for me. Sending SIGUSR2 to
> the master process now works as expected. Is that option required for this
> reload model?

"expose-fd listeners" is the option which give the ability to the admin socket
to pass the listeners FDs, so this option is mandatory if you want to use the
seamless reload.

When you use the 'normal' daemon model, you have to specify -x with the path of
the socket where you want to retrieve the listeners.

Using the master-worker you only need to specify "expose-fd listeners" in the
config, and the master will use this socket and reexecute itself with the right
"-x" option.

> > Did you try launching a new haproxy process with the -sf option, without
> > using the master-worker?
> 
> Yes, and that also failed with the same "cannot bind" error.

Without "expose-fd listeners" I suppose?

> > What is your operating system and version exactly?
> 
> We are using SmartOS:
> # uname -a
> SunOS ops-dev-lb03 5.11 joyent_20170315T185612Z i86pc i386 i86pc Solaris
> 
> > I think the old processes did not receive the SIGTTOU for an unknown
> > reason, or did not unbind once it received the signal.
> 
> > Maybe you could try to compare what's happening on your solaris-like system
> > and your ubuntu with the -dR option, using strace on linux and truss on
> > solaris.
> 
> I verified using dtrace that the worker is indeed receiving the SIGTTOU
> signal from the master (200 times), so the worker must not have been
> unbinding.
> 

Okay, so it looks like that the unbinding with SIGTOUT does not work on your
OS, but the seamless reload seems to work...

According to the code commentary that's a known problem on Solaris, maybe we
should add a note in the documentation about it.

Regards,

-- 
William Lallemand

Re: Testing master-worker reloads on HAProxy 1.8

[Anthony Via]

> Did you try the seamless reload using -x without the master-worker?

I was looking into the "-x" option and it looks like simply adding "expose-fd 
listeners" to my stats socket has fixed this issue for me. Sending SIGUSR2 to 
the master process now works as expected. Is that option required for this 
reload model?

> Did you try launching a new haproxy process with the -sf option, without using
the master-worker?

Yes, and that also failed with the same "cannot bind" error.

> What is your operating system and version exactly?

We are using SmartOS:
# uname -a
SunOS ops-dev-lb03 5.11 joyent_20170315T185612Z i86pc i386 i86pc Solaris

> I think the old processes did not receive the SIGTTOU for an unknown reason,
or did not unbind once it received the signal.

> Maybe you could try to compare what's happening on your solaris-like system 
> and
your ubuntu with the -dR option, using strace on linux and truss on solaris.

I verified using dtrace that the worker is indeed receiving the SIGTTOU signal 
from the master (200 times), so the worker must not have been unbinding.


Anthony



From: William Lallemand 
Sent: Friday, December 8, 2017 1:54 PM
To: Anthony Via
Cc: haproxy@formilux.org
Subject: Re: Testing master-worker reloads on HAProxy 1.8

> On Wed, Dec 06, 2017 at 10:48:23PM +, Anthony Via wrote:
> > I am testing seamless reloads on HAProxy 1.8.0 using the master-worker
> > model and am running into the following when sending SIGUSR2 to the master
> > process

Sorry I misread, my explanation in the previous post is not correct for the
seamless reload (-x + expose-fd), but only for a "classic" reload.

During a seamless reload, the new process try to get the FDs of the listeners
using the unix socket.

Did you try the seamless reload using -x without the master-worker?

--
William Lallemand

Re: haproxy 1.8 seems to be using wrong backend

[Lukas Tribus]

Hell Chris,


2017-12-11 20:04 GMT+01:00 Christian Bönning :
> Hi,
>
> I recently switched from nginx to haproxy 1.8 for SSL termination and load 
> balancing in front of my application but saw an odd behaviour with "alpn 
> h2,http/1.1" enabled on my frontend.
>
> I'm running a single haproxy instance in front of my applications switching 
> between them based on "ssl_fc_sni" or HTTP host.
> [...]
> use_backend backend_app_jira if { ssl_fc_sni -i jira.example.com || hdr(host) 
> -i jira.example.com }
> use_backend backend_app_confluence if { ssl_fc_sni -i confluence.example.com 
> || hdr(host) -i confluence.example.com }

That's whats wrong. You can't route based on ssl_fc_sni or HTTP Host.
This will lead to the this exact behavior.

You have to route based on HTTP Host header *only*. The SNI value will
be "jira.example.com" for the entire H2 (or H1) session, even when you
request something on confluence - that is if your certificate handles
both domains. SNI is for certificate selection only, you need to look
at host header (*only*), for deciding with backend to choose for a
specific HTTP transaction.


The difference between h2 and http/1.1 is that h2 keeps the SSL
session alive for a longer time (timeout server or timeout client)
than http/1.1 (timeout http-keep-alive). You browser may also not
reuse the SSL session for a different domain in http/1.1, while it
does soin h2. So that's why you may see different behavior in h2,
depending on your browser.



Regards,
Lukas

Re: Incredible performance bump between 1.5.12 and 1.8.1 ?

[Christopher Lane]

On Sat, Dec 9, 2017 at 10:18 PM, Willy Tarreau  wrote:
> On Sat, Dec 09, 2017 at 10:10:25AM +0100, Pavlos Parissis wrote:
>> On 09/12/2017 05:01 ?u, Christopher Lane wrote:
>> > It is plausible/expected that my version upgrade performance goes like 
>> > (about 4K connections,
>> > long lived and short lived mix, TCP only, no HTTP:
>> >
>> > 1.5.12 (nproc 1, old connections causing about 100 old -sf processes to 
>> > linger) uses 100% CPU
>> > almost all the time, frequently with >1 process.  (100%, 75%, 48%, ... ).  
>> > Highest CPU user has
>> > 2-3K connections.
>> >
>> > 1.8.1 (nbproc 4, with hard-stop-after 600s) using like 1%, 3%, 3%, 8% CPU  
>> > Also 2-3K
>> > connections.
>> >
>>
>> You compare multi-process setup with a single process setup, which isn't a
>> fair comparison.
>> Do you see the same the performance increase with 1.8.1, when you configure
>> it with one process?
>
> Good observation! Also I'd add that concurrent connections alone have no
> impact on CPU usage but on memory. The only exception is if you're using
> a low performance poller like poll() instead of epoll or kqueue. This is
> visible in haproxy -vv and might happen if the previous version was built
> for a generic OS.
>
> Cheers,
> Willy

Ahh, yes, poll vs. epoll may explain it:

The 1.5.1 -vv is:

 /usr/local/sbin/haproxy -vv
HA-Proxy version 1.5.12 2015/05/02
Copyright 2000-2015 Willy Tarreau 

Build options :
  TARGET  = generic
  CPU = generic
  CC  = gcc
  CFLAGS  = -O2 -g -fno-strict-aliasing
  OPTIONS = USE_OPENSSL=1

Default settings :
  maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200

Encrypted password support via crypt(3): no
Built without zlib support (USE_ZLIB not set)
Compression algorithms supported : identity
Built with OpenSSL version : OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
Running on OpenSSL version : OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : no (version might be too old, 0.9.8f min needed)
OpenSSL library supports prefer-server-ciphers : yes
Built without PCRE support (using libc's regex instead)

Available polling systems :
   poll : pref=200,  test result OK
 select : pref=150,  test result OK
Total: 2 (2 usable), will use poll.


And 1.8.1:

/usr/local/sbin/haproxy.1.8.1 -vv
HA-Proxy version 1.8.1 2017/12/03
Copyright 2000-2017 Willy Tarreau 

Build options :
  TARGET  = linux26
  CPU = generic
  CC  = gcc
  CFLAGS  = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement
-fwrapv -Wno-unused-label
  OPTIONS = USE_LINUX_TPROXY=1 USE_ZLIB=1 USE_CPU_AFFINITY=1
USE_OPENSSL=1 USE_STATIC_PCRE=1

Default settings :
  maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Built with OpenSSL version : OpenSSL 1.0.2k  26 Jan 2017
Running on OpenSSL version : OpenSSL 1.0.2k  26 Jan 2017
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : SSLv3 TLSv1.0 TLSv1.1 TLSv1.2
Built with transparent proxy support using: IP_TRANSPARENT
IPV6_TRANSPARENT IP_FREEBIND
Encrypted password support via crypt(3): yes
Built with PCRE version : 6.6 06-Feb-2006
Running on PCRE version : 6.6 06-Feb-2006
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Built with zlib version : 1.2.3
Running on zlib version : 1.2.3
Compression algorithms supported : identity("identity"),
deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with network namespace support.

Available polling systems :
  epoll : pref=300,  test result OK
   poll : pref=200,  test result OK
 select : pref=150,  test result OK
Total: 3 (3 usable), will use epoll.

Available filters :
[SPOE] spoe
[COMP] compression
[TRACE] trace

Nice to know the real root cause, although we are going to try 1.5
with the correct health check just to see.

Re[2]: Use haproxy 1.8.x to balance web applications only reachable through Internet proxy

[Aleksandar Lazic]

Hi.

-- Originalnachricht --
Von: "Moemen MHEDHBI" 
An: "Gbg" ; haproxy@formilux.org
Gesendet: 11.12.2017 18:45:16
Betreff: Re: Use haproxy 1.8.x to balance web applications only 
reachable through Internet proxy



On 11/12/2017 17:21, Gbg wrote:

Hello  Moemen,

 unless I got this wrong this isn't the setup I search for. I 
don't  need haproxy to *be* a proxy but rather *use* a proxy while 
 serving content over http as a reverse proxy


 Perhaps I should have given the thread this name


   I get your point, HAProxy does not support using a "http/socks
proxy".
   HAProxy intends to be "an HTTP reverse-proxy" retrieving resources   
 from backend servers and the requests sent to a server are different   
 from the ones sent to a "forward proxy".
   That being said HAProxy  can still "pass" proxy requests to
http/socks proxies if the client is configured to use a proxy.
How about to use delegate ( http://delegate.org/documents/ ) for this, 
just as an idea.


haproxy -> delegate FORWARD=... CONNECT=proxy:

http://delegate.org/delegate/Manual.shtml?FORWARD
http://delegate.org/delegate/Manual.shtml?CONNECT

I know it's not that elegant but it could work.



   ++


Am 11. Dezember 2017 16:56:12 MEZ schriebMoemen MHEDHBI 
 :

On 11/12/2017 15:02, Gbg wrote:


 I need to contact applications through a socks or http proxy.

 My current setup looks like this but only works when the Computer
 haproxy runs on has direct Internet connection (which is not the case
 in our datacenter, I tried this at home)

 frontend main
 bind *:8000
 acl is_extweb1 path_beg -i /policies
 acl is_extweb2 path_beg -i /produkte
 use_backend externalweb1 if is_extweb1
 use_backend externalweb2 if is_extweb2

 backend externalweb1
 server static www.google.com:80 check

 backend externalweb2
 server static www.gmx.net:80 check

 There is an SO post which addresses the same question and provides
 some more details:
 
https://stackoverflow.com/questions/47605766/use-haproxy-as-an-reverse-proxy-with-an-application-behind-internet-proxy





Hi Gbg,

For this to work you need the client (browser for example) to be aware
of the forward proxy.
So first you need to configure the client to use HAProxy as a forward
proxy, then in the HAProxy conf you need to use the forward proxy in the
backend and the configuration may look like this:

frontend main
bind *:8000
acl is_extweb path_beg -i /policies /produkte
use_backend forward_proxy if is_extweb
default_backend another_backend

backend forward_proxy
  server static < IP-of-the-forward-proxy > : < Port > check


++

Moemen MHEDHBI






 --
 Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail  
gesendet.


--
Moemen MHEDHBI

haproxy 1.8 seems to be using wrong backend

[Christian Bönning]

Hi,

I recently switched from nginx to haproxy 1.8 for SSL termination and load 
balancing in front of my application but saw an odd behaviour with "alpn 
h2,http/1.1" enabled on my frontend.

I'm running a single haproxy instance in front of my applications switching 
between them based on "ssl_fc_sni" or HTTP host. However once a request comes 
in the first requests are passed to the correct backend server (let's call it 
jira.example.com). If I open another browser-session (same browser, another 
tab) to open a second application terminated by that haproxy instance - 
quickly, I assume before the tcp session times out (let's call this 
confluence.example.com) chances are pretty high my requests will be passed to 
jira backend servers, though on the logs it shows it found the correct HTTP 
host, but routing requests to the wrong backend service.

All requests are routed fine (even under heavy load) once I remove "h2" from 
alpn on my frontend. Tried option httpclose and option http-server-close on 
"their" places beforehand, but had no luck with those. Removing h2 seemed the 
only solution for now as it seemed as haproxy does behave properly in this case.

I'm currently using haproxy 1.8.1 from haproxy.debian.net:
HA-Proxy version 1.8.1-1~bpo9+1 2017/12/04
Copyright 2000-2017 Willy Tarreau 

You can find my haproxy config (stripped down to the relavant parts - in the 
end I'm running just "more" applications on this instance) here:
https://gist.github.com/hexa2k9/b5b31c09990e9ac15be07285e6fff3e5

If further info is needed will be happy to provide. Any hints appreciated.

Cheers,
Chris



smime.p7s
Description: S/MIME cryptographic signature

Re: Use haproxy 1.8.x to balance web applications only reachable through Internet proxy

[Moemen MHEDHBI]

On 11/12/2017 17:21, Gbg wrote:
> Hello Moemen,
>
> unless I got this wrong this isn't the setup I search for. I don't
> need haproxy to *be* a proxy but rather *use* a proxy while serving
> content over http as a reverse proxy
>
> Perhaps I should have given the thread this name

I get your point, HAProxy does not support using a "http/socks proxy".
HAProxy intends to be "an HTTP reverse-proxy" retrieving resources from
backend servers and the requests sent to a server are different from the
ones sent to a "forward proxy".
That being said HAProxy  can still "pass" proxy requests to http/socks
proxies if the client is configured to use a proxy.

++
>
> Am 11. Dezember 2017 16:56:12 MEZ schrieb Moemen MHEDHBI
> :
>
>
> On 11/12/2017 15:02, Gbg wrote:
>
> I need to contact applications through a socks or http proxy.
> My current setup looks like this but only works when the
> Computer haproxy runs on has direct Internet connection (which
> is not the case in our datacenter, I tried this at home)
> frontend main bind *:8000 acl is_extweb1 path_beg -i /policies
> acl is_extweb2 path_beg -i /produkte use_backend externalweb1
> if is_extweb1 use_backend externalweb2 if is_extweb2 backend
> externalweb1 server static www.google.com:80 check backend
> externalweb2 server static www.gmx.net:80 check There is an SO
> post which addresses the same question and provides some more
> details:
> 
> https://stackoverflow.com/questions/47605766/use-haproxy-as-an-reverse-proxy-with-an-application-behind-internet-proxy
>
>
>
>
>
> Hi Gbg,
>
> For this to work you need the client (browser for example) to be aware
> of the forward proxy.
> So first you need to configure the client to use HAProxy as a forward
> proxy, then in the HAProxy conf you need to use the forward proxy in the
> backend and the configuration may look like this:
>
> frontend main
> bind *:8000
> acl is_extweb path_beg -i /policies /produkte
> use_backend forward_proxy if is_extweb
> default_backend another_backend
>
> backend forward_proxy
>   server static < IP-of-the-forward-proxy > : < Port > check
>
>
> ++
>
> Moemen MHEDHBI
>
>
>
>
> -- 
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. 

-- 
Moemen MHEDHBI

Re: Use haproxy 1.8.x to balance web applications only reachable through Internet proxy

[Gbg]

Hello Moemen, 

unless I got this wrong this isn't the setup I search for. I don't need haproxy 
to *be* a proxy but rather *use* a proxy while serving content over http as a 
reverse proxy

Perhaps I should have given the thread this name

Am 11. Dezember 2017 16:56:12 MEZ schrieb Moemen MHEDHBI :
>
>
>On 11/12/2017 15:02, Gbg wrote:
>> I need to contact applications through a socks or http proxy.
>>
>> My current setup looks like this but only works when the Computer
>> haproxy runs on has direct Internet connection (which is not the case
>> in our datacenter, I tried this at home)
>>
>> frontend main
>> bind *:8000
>> acl is_extweb1 path_beg -i /policies
>> acl is_extweb2 path_beg -i /produkte
>> use_backend externalweb1 if is_extweb1
>> use_backend externalweb2 if is_extweb2
>>
>> backend externalweb1
>> server static www.google.com:80 check
>>
>> backend externalweb2
>> server static www.gmx.net:80 check
>>
>> There is an SO post which addresses the same question and provides
>> some more details:
>>
>https://stackoverflow.com/questions/47605766/use-haproxy-as-an-reverse-proxy-with-an-application-behind-internet-proxy
>
>
>
>Hi Gbg,
>
>For this to work you need the client (browser for example) to be aware
>of the forward proxy.
>So first you need to configure the client to use HAProxy as a forward
>proxy, then in the HAProxy conf you need to use the forward proxy in
>the
>backend and the configuration may look like this:
>
>frontend main
>bind *:8000
>acl is_extweb path_beg -i /policies /produkte
>use_backend forward_proxy if is_extweb
>default_backend another_backend
>
>backend forward_proxy
>  server static < IP-of-the-forward-proxy > : < Port > check
>
>
>++
>
>Moemen MHEDHBI

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Use haproxy 1.8.x to balance web applications only reachable through Internet proxy

[Moemen MHEDHBI]

On 11/12/2017 15:02, Gbg wrote:
> I need to contact applications through a socks or http proxy.
>
> My current setup looks like this but only works when the Computer
> haproxy runs on has direct Internet connection (which is not the case
> in our datacenter, I tried this at home)
>
> frontend main
> bind *:8000
> acl is_extweb1 path_beg -i /policies
> acl is_extweb2 path_beg -i /produkte
> use_backend externalweb1 if is_extweb1
> use_backend externalweb2 if is_extweb2
>
> backend externalweb1
> server static www.google.com:80 check
>
> backend externalweb2
> server static www.gmx.net:80 check
>
> There is an SO post which addresses the same question and provides
> some more details:
> https://stackoverflow.com/questions/47605766/use-haproxy-as-an-reverse-proxy-with-an-application-behind-internet-proxy



Hi Gbg,

For this to work you need the client (browser for example) to be aware
of the forward proxy.
So first you need to configure the client to use HAProxy as a forward
proxy, then in the HAProxy conf you need to use the forward proxy in the
backend and the configuration may look like this:

frontend main
bind *:8000
acl is_extweb path_beg -i /policies /produkte
use_backend forward_proxy if is_extweb
default_backend another_backend

backend forward_proxy
  server static < IP-of-the-forward-proxy > : < Port > check


++

Moemen MHEDHBI

Re: [PATCH] BUG: NetScaler CIP handling is incorrect

[Bertrand Jacquin]

Hi Andreas,

I got this really side tracked, my apology. Let me take a look at that
this evening again. Some corps need to be unburied.

I'm afraid the patch, as is, will break compatibility with other version
of the CIP protocol, I'd like haproxy to support both of them.

Cheers,
Bertrand

On 07/12/17 13:41, Andreas Mahnke wrote:
> Hello everybody,
> 
> Is there an update regarding the merging of the patch? We are thinking
> to switch to version 1.8 in the near future and it would be nice to have
> the patch merged, so that we do not need to merge each update on our own.
> 
> Best regards,
> Andreas
> 
> On Fri, Jul 7, 2017 at 2:43 PM, Willy Tarreau  > wrote:
> 
> On Fri, Jul 07, 2017 at 02:36:07PM +0200, Andreas Mahnke wrote:
> > Hi Willy,
> >
> > I had some direct mail conversations with him and he wanted to create a
> > patch based in the findings.
> > In the meantime we got it working using the patch I provided, therefore 
> I
> > sent it yesterday so that it gets integrated and we do not need to patch
> > haproxy on our end everytime a new version comes out.
> >
> > I wrote him yesterday that the patch was sent by me, but he seems to be 
> out
> > of office until monday - so maybe he will get back to us then.
> 
> Yep I noticed the out-of-office notification as well. Let's wait for
> him to
> get back. I'm pretty fine with merging your patch, I just want to be
> certain
> that everything is OK on his side as well, especially before
> backporting it
> (since it's a bug fix).
> 
> Thanks!
> Willy
> 
> 

-- 
Bertrand
Payments Infrastructure Engineering, Amazon



signature.asc
Description: OpenPGP digital signature
Amazon Data Services Ireland Limited registered office: One Burlington Plaza, 
Burlington Road, Dublin 4, Ireland. Registered in Ireland. Registration number 
390566.

Use haproxy 1.8.x to balance web applications only reachable through Internet proxy

[Gbg]

I need to contact applications through a socks or http proxy.

My current setup looks like this but only works when the Computer haproxy runs 
on has direct Internet connection (which is not the case in our datacenter, I 
tried this at home)

frontend main
 bind *:8000
 acl is_extweb1 path_beg -i /policies
 acl is_extweb2 path_beg -i /produkte
 use_backend externalweb1 if is_extweb1
 use_backend externalweb2 if is_extweb2 

backend externalweb1 
 server static www.google.com:80 check

backend externalweb2
 server static www.gmx.net:80 check

There is an SO post which addresses the same question and provides some more 
details:
https://stackoverflow.com/questions/47605766/use-haproxy-as-an-reverse-proxy-with-an-application-behind-internet-proxy

Re: Quick update on pending HTTP/2 issues

[Willy Tarreau]

Hi Lukas,

On Mon, Dec 11, 2017 at 11:54:07AM +0100, Lukas Tribus wrote:
> Hello Willy,
> 
> 
> 
> 2017-12-07 19:55 GMT+01:00 Willy Tarreau :
> > Guys,
> >
> > just to warn you, there's currently an issue affecting HTTP/2 with POST
> > payloads to "slow" servers.
> 
> Ok, the POST issue is obviously more important, but just to provide a
> complete picture we also have those 2 minor issues left in H2, which
> can easily be worked around though:
> 
> - the abortonclose incompatibility:
> https://www.mail-archive.com/haproxy@formilux.org/msg28186.html

Yes I'm well aware of the abortonclose issue indeed, and as you're
saying, at the moment it's less important for me since there is a
workaround.

> - improper close (no GOAWAY) when "timeout server" < "timeout client"
> https://www.mail-archive.com/haproxy@formilux.org/msg27990.html

Thanks for the reminder, I already forgot about this one :-)

> Also, a quick reminder about 1.7.10; I can see a lot of patches are
> already backported, is there still something missing?

I don't know yet. From what I can see in 1.8, part of the truncated
objects are caused by H2 itself, and other parts are caused by a bad
behaviour of the HTTP forwarding code when facing a SHUTR (it's
considered as an abort even in cases where we can't move due to a
buffer full condition). So we may end up having to backport a fix
there. Also I'd like to re-run a number of non-reg tests on 1.7.10
before we release it.

Thanks!
Willy

Re: Quick update on pending HTTP/2 issues

[Lukas Tribus]

Hello Willy,



2017-12-07 19:55 GMT+01:00 Willy Tarreau :
> Guys,
>
> just to warn you, there's currently an issue affecting HTTP/2 with POST
> payloads to "slow" servers.

Ok, the POST issue is obviously more important, but just to provide a
complete picture we also have those 2 minor issues left in H2, which
can easily be worked around though:

- the abortonclose incompatibility:
https://www.mail-archive.com/haproxy@formilux.org/msg28186.html

- improper close (no GOAWAY) when "timeout server" < "timeout client"
https://www.mail-archive.com/haproxy@formilux.org/msg27990.html



Also, a quick reminder about 1.7.10; I can see a lot of patches are
already backported, is there still something missing?




Thanks,

Lukas