CI/CD HAProxy

[Olivier Doucet]

Hi,

I wanted to open a new thread, as "cppcheck finding" was hijacked with this
CICD / testing ;)

I think the best is the enemy of the good : why not start with a few easy
tests ? For example just a mix of tiny / big config files to test the
parser.

I understand the difficult part of the test is to setup complicated
infrastructures with many softwares to test edge cases, but that can be
done later.

Willy, there is no need to setup and maintain a buildfarm (no one has time
for this) : as this is an open project, we can use platform like Travis-CI
: all tests are described in a yaml file incorporated in the project. It
works out of the box for any project hosted at github. We can use a mirror
for this.

What is great about these is that you can easily plug syntax check
softwares ;)

Olivier

Re: cppcheck finding

[Cyril Bonté]

Hi all,

Le 15/09/2017 à 18:40, Willy Tarreau a écrit :

I once had an interesting discussion with PHK who proposed to extend
the varnish test program to also cover haproxy so that we could write
various test cases, as he wrote this tool to address exactly the same
issue. It could be an option, but I didn't have time (nor do I now) to
look into that.


I also wanted to explore that possibility, but unfortunately I'm not 
able to find time yet, too :-/


I had some ideas to automatically generate test configurations, 
randomizing keyword orders for example, to validate the config parser, 
the expected behaviour and to ensure there is no regression between 
versions. The only issue is that it requires some time :)



--
Cyril Bonté

more cppcheck findings

[Илья Шипицин]

hello,

[contrib/halog/halog.c:1572]: (error) Memory leak: ustat
[contrib/mod_defender/defender.c:153]: (error) va_list 'argp' was opened
but not closed by va_end().
[contrib/modsecurity/modsec_wrapper.c:109]: (error) va_list 'ap' was opened
but not closed by va_end().
[src/51d.c:373]: (error) Invalid number of character '{' when no macros are
defined.
[src/dns.c:2502]: (error) Memory leak: buffer
[src/haproxy.c:568]: (error) Common realloc mistake: 'next_argv' nulled but
not freed upon failure


cheers,
Ilya Shipitsin

Re: cppcheck finding

[Willy Tarreau]

On Fri, Sep 15, 2017 at 03:04:26PM +0200, Christopher Faulet wrote:
> You're right, there are bugs there. The worst is on the compression filter.
> I attached patches to fix them.
> 
> Willy, could you merge it please ? Some of them must be backported in 1.7.

Now applied, thanks Christopher.

Willy

Re: cppcheck finding

[Willy Tarreau]

Hi Aleks,

On Fri, Sep 15, 2017 at 06:29:42PM +0200, Aleksandar Lazic wrote:
> Hi.
> 
> Willy Tarreau wrote on 15.09.2017:
> 
> > On Fri, Sep 15, 2017 at 06:36:20PM +0500,  ??? wrote:
> >> I'd say, it's chicken and egg situation. Whichever comes first, tests or 
> >> CI.
> >> if we start a CI with "just build", it will evolve, people will start
> >> writing tests (I beleive so)
> 
> > I tend to believe it as well. However what I'm less convinced about is
> > the long term maintenance of such an infrastructure. People tend to
> > volunteer to set up stuff initially because it improves a situation but
> > after 3 or 4 years they have other things to do and nobody maintains
> > what they built anymore. We've seen this in the past with other stuff
> > like a translated version of the web site for example. It's more
> > important to spot who is willing to step up on this and to be sure to
> > maintain it for a while and at least long enough to pass it to someone
> > else once they start to get fed up.
> 
> I have created a build ci on gitlab.
> 
> https://gitlab.com/aleks001/haproxy17-centos/tree/master
> 
> The test would be very difficult due to the fact that you should have at 
> least a backend <-> haproxy <-> client and what Test should be run?

Hehe welcome to the real world guys ;-)

Yes testing an intermediary is a real pain as it requires acting on both
sides at once. When you look at tests/test-fsm.cfg you start to realize
the type of pain it is, and this file doesn't even test 0.1% of the
internals, it just validates that we didn't break too much something
very obvious.

> When you take a look into the features of haproxy ;-) it's a huge task.
> 
> I suggest to use caddy as simple webserver or can we use the error_file 
> function to deliver some content from haproxy?

I tend to use netcat, openssl, socat, curl, httpterm, inject, haproxy
(yes, itself). Also writing config files involving multiple features at
once by chaining instances works pretty well (ie ssl, proxy protocol
etc). But even then it's a pain and it tests very very little of it.

I once had an interesting discussion with PHK who proposed to extend
the varnish test program to also cover haproxy so that we could write
various test cases, as he wrote this tool to address exactly the same
issue. It could be an option, but I didn't have time (nor do I now) to
look into that.

Cheers,
Willy

Re: cppcheck finding

[Илья Шипицин]

2017-09-15 21:29 GMT+05:00 Aleksandar Lazic :

> Hi.
>
> Willy Tarreau wrote on 15.09.2017:
>
> > On Fri, Sep 15, 2017 at 06:36:20PM +0500,  ??? wrote:
> >> I'd say, it's chicken and egg situation. Whichever comes first, tests
> or CI.
> >> if we start a CI with "just build", it will evolve, people will start
> >> writing tests (I beleive so)
>
> > I tend to believe it as well. However what I'm less convinced about is
> > the long term maintenance of such an infrastructure. People tend to
> > volunteer to set up stuff initially because it improves a situation but
> > after 3 or 4 years they have other things to do and nobody maintains
> > what they built anymore. We've seen this in the past with other stuff
> > like a translated version of the web site for example. It's more
> > important to spot who is willing to step up on this and to be sure to
> > maintain it for a while and at least long enough to pass it to someone
> > else once they start to get fed up.
>
> I have created a build ci on gitlab.
>
> https://gitlab.com/aleks001/haproxy17-centos/tree/master



there's more easy way of using docker images with gitlab-ci,
for example:

https://gitlab.com/chipitsine/openvpn/blob/master/.gitlab-ci.yml


also, gitlab is very flexible, in the example above I use "shared" runners.
and, if we want to maintain, we can attach own runners as well


>
>
> The test would be very difficult due to the fact that you should have at
> least a backend <-> haproxy <-> client and what Test should be run?
>
> When you take a look into the features of haproxy ;-) it's a huge task.
>

yep


>
> I suggest to use caddy as simple webserver or can we use the error_file
> function to deliver some content from haproxy?
>
> > Cheers,
> > Willy
>
>
> --
> Best Regards
> Aleks
>
>

Re: cppcheck finding

[Aleksandar Lazic]

Hi.

Willy Tarreau wrote on 15.09.2017:

> On Fri, Sep 15, 2017 at 06:36:20PM +0500,  ??? wrote:
>> I'd say, it's chicken and egg situation. Whichever comes first, tests or CI.
>> if we start a CI with "just build", it will evolve, people will start
>> writing tests (I beleive so)

> I tend to believe it as well. However what I'm less convinced about is
> the long term maintenance of such an infrastructure. People tend to
> volunteer to set up stuff initially because it improves a situation but
> after 3 or 4 years they have other things to do and nobody maintains
> what they built anymore. We've seen this in the past with other stuff
> like a translated version of the web site for example. It's more
> important to spot who is willing to step up on this and to be sure to
> maintain it for a while and at least long enough to pass it to someone
> else once they start to get fed up.

I have created a build ci on gitlab.

https://gitlab.com/aleks001/haproxy17-centos/tree/master

The test would be very difficult due to the fact that you should have at 
least a backend <-> haproxy <-> client and what Test should be run?

When you take a look into the features of haproxy ;-) it's a huge task.

I suggest to use caddy as simple webserver or can we use the error_file 
function to deliver some content from haproxy?

> Cheers,
> Willy


-- 
Best Regards
Aleks

Re: Kernel TLS for http/2

[Emmanuel Hocdet]

Hi,

> Le 14 sept. 2017 à 19:34, Lukas Tribus  a écrit :
> 
> Hello,
> 
> 
> Am 05.09.2017 um 10:00 schrieb Willy Tarreau:
>> 
>> As I already mentionned (I don't remember to whom), I really don't see *any*
>> benefit in this approach and only problems in fact. By the way, others have
>> attempted it in the past and failed.
> 
> I agree, when we are talking about the haproxy use case (which is
> always network to network).
> 
> I do find the combination between sendfile and ktls is very interesting
> though, for web servers that are waiting for the disk, especially
> event-loop based software like nginx.
> 
> 
> For haproxy on the other side symmetric crypto performance is not the
> problem; asymmetric crypto performance (the handshake) is, because it
> it is blocking the event-loop.
> 
> Pushing the handshake to worker thread(s) is a possible solution to this,
> and I guess would probably eliminate the main reason people have to use
> nbproc > 1 today.
> 

This is an excellent improvement. And traffic for established connections
is no longer disturbed by handshake.

> I believe this was discussed before and is indeed something Willy has
> on his mind.

I think is the case with ssl-mode-async in 1.8. It depend on openssl-version.
I hope this will be generalisable in a native async HS.

> 
> How difficult the OpenSSL API makes this, I'm not sure. The documentation
> certainly leaves "room for improvement" in regard to threading:
> 
> https://www.openssl.org/blog/blog/2017/02/21/threads/ 
> 
> https://github.com/openssl/openssl/issues/2165 
> 
> 
> 

++
Manu

Re: Dynamic server name with HAProxy, based on original hostname

[Ludovic Gasc]

I have tested with HAProxy 1.7.

Where you see that it's a feature of 1.8 ?
You mean I could try my piece of configuration on HAProxy 1.8, it should
work ?

Regards.

2017-09-15 14:47 GMT+02:00 Igor Cicimov :

>
>
> On Fri, Sep 15, 2017 at 9:25 PM, Ludovic Gasc  wrote:
>
>> Hi,
>>
>> I imagine that if I have no answer, it's because it isn't possible with
>> HAProxy ?
>>
>> Thanks for your return.
>>
>>
>> 2017-09-10 22:27 GMT+02:00 Ludovic Gasc :
>>
>>> Hi,
>>>
>>> I'm trying to reproduce this Nginx configuration with HAProxy:
>>> https://memz.co/reverse-proxy-nginx-docker-microservices/
>>>
>>> Where it's possible to use DNS as dynamic list to proxy to the right
>>> server.
>>> Our use case isn't container-related, but simply to move easily a
>>> customer from a backend server to another one, without to change the
>>> HAproxy configuration.
>>>
>>> The closest feature in HAProxy seems to be option http_proxy, however,
>>> no DNS lookup is performed:
>>> http://cbonte.github.io/haproxy-dconv/configuration-1.7.html
>>> #4.2-option%20http_proxy
>>>
>>> I have tried to use a resolver in haproxy configuration + in backend
>>> section:
>>>   server XX %[hdr(host)]: resolvers dns
>>> check inter 1000 init-addr last,libc,127.0.0.1
>>>
>>> However, it doesn't work.
>>>
>>> Maybe with a lua script it's possible to implement that, but I would
>>> prefer to have a simple configuration like with Nginx.
>>>
>>> Do I missed something ?
>>>
>>> BTW, thanks for HAProxy, I like a lot this product ;-)
>>>
>>> Regards.
>>> --
>>> Ludovic Gasc (GMLudo)
>>>
>>
>>
> ​This should be a feature in 1.8, which version did you try?​
>
>

Re: cppcheck finding

[Willy Tarreau]

On Fri, Sep 15, 2017 at 06:36:20PM +0500,  ??? wrote:
> I'd say, it's chicken and egg situation. Whichever comes first, tests or CI.
> if we start a CI with "just build", it will evolve, people will start
> writing tests (I beleive so)

I tend to believe it as well. However what I'm less convinced about is
the long term maintenance of such an infrastructure. People tend to
volunteer to set up stuff initially because it improves a situation but
after 3 or 4 years they have other things to do and nobody maintains
what they built anymore. We've seen this in the past with other stuff
like a translated version of the web site for example. It's more
important to spot who is willing to step up on this and to be sure to
maintain it for a while and at least long enough to pass it to someone
else once they start to get fed up.

Cheers,
Willy

Re: Long Running TCP Connections and Reloads

[Pean, David S.]

We are using a patched version from April that fixed a big memory leak that 
occurred on another project, so it looks like it would have had that fix.

HAPROXY_VERSION=1.7.7a450ca
HAPROXY_MD5=fa9c6d9af600e12ef31567b941fa1dfb

Dave

From: "Krishna Kumar (Engineering)" 
>
Date: Friday, September 15, 2017 at 1:23 AM
To: "david.s.p...@espn.com" 
>
Cc: "haproxy@formilux.org" 
>
Subject: Re: Long Running TCP Connections and Reloads

Regarding #1, I think this was fixed sometime back. Maybe you are running
a old version of haproxy?

commit e39683c4d4c527d1b561c3ba3983d26cc3e7f42d
Author: Hongbo Long >
Date:   Fri Mar 10 18:41:51 2017 +0100

BUG/MEDIUM: stream: fix client-fin/server-fin handling

A tcp half connection can cause 100% CPU on expiration.



On Thu, Sep 14, 2017 at 6:59 PM, Pean, David S. 
> wrote:
Hello!

I am using a TCP front-end that potentially keeps connections open for several 
hours, while also frequently issuing reloads due to an id to server mapping 
that is changing constantly. This causes many processes to be running at any 
given time, which generally works as expected. However, after some time I see 
some strange behavior with the processes and stats that doesn’t appear to have 
any pattern to it.

Here is the setup in general:

Every two minutes, there is a process that checks if HAProxy should be 
reloaded. If that is the case, this command is run:

/usr/local/sbin/haproxy -D –f -sf PID

The PID is the current HAProxy process. If there are TCP connections to that 
process, it will stay running until those connection drop, then generally it 
will get killed.

1. Sometimes a process will appear to not get killed, and have no connections. 
It will be running for several hours and have 99 CPU. When straced, it doesn't 
appear to be actually doing anything -- just clock and polls very frequently. 
Is there some sort of timeout for the graceful shutdown of the old processes?

2. Is it possible for the old processes to accept new connections? Even though 
a pid has been sent the shutdown signal, I have seen requests reference old 
server mappings that would have been in an earlier process.

3. Often the stats page will become out of whack over time. The number of 
requests per second will become drastically different from what is actually 
occuring. It looks like the old stuck processes might be sending more data that 
is maybe not getting cleared?

Are there any considerations for starting up or reloading when dealing with 
long running connections?

Thanks!

David Pean

Re: cppcheck finding

[Илья Шипицин]

2017-09-15 18:22 GMT+05:00 Christopher Faulet :

> Le 15/09/2017 à 15:07, Илья Шипицин a écrit :
>
>> and what about CI ?
>>
>> something like gitlab-ci, travis, jenkins ? I'll invest some efforts in
>> that
>>
>>
> No CI. This would be useful to have one but we have no time to work on it
> for now. Having a CI is not a big deal. The harder is to write tests and
> set up and maintain the build/test matrix.
>


I'd say, it's chicken and egg situation. Whichever comes first, tests or CI.
if we start a CI with "just build", it will evolve, people will start
writing tests (I beleive so)


>
> --
> Christopher Faulet
>

Re: cppcheck finding

[Christopher Faulet]

Le 15/09/2017 à 15:07, Илья Шипицин a écrit :

and what about CI ?

something like gitlab-ci, travis, jenkins ? I'll invest some efforts in that



No CI. This would be useful to have one but we have no time to work on 
it for now. Having a CI is not a big deal. The harder is to write tests 
and set up and maintain the build/test matrix.


--
Christopher Faulet

Re: cppcheck finding

[Илья Шипицин]

and what about CI ?

something like gitlab-ci, travis, jenkins ? I'll invest some efforts in that

2017-09-15 18:04 GMT+05:00 Christopher Faulet :

> Le 15/09/2017 à 08:36, Илья Шипицин a écrit :
>
>> great, thank for the feedback.
>>
>> there're few things like that
>>
>> [src/flt_http_comp.c:926] -> [src/flt_http_comp.c:926]: (warning) Either
>> the condition 'txn' is redundant or there is possible null pointer
>> dereference: txn.
>> [src/flt_spoe.c:2765] -> [src/flt_spoe.c:2766]: (warning) Either the
>> condition 'ctx==NULL' is redundant or there is possible null pointer
>> dereference: ctx.
>> [src/haproxy.c:568]: (error) Common realloc mistake: 'next_argv' nulled
>> but not freed upon failure
>> [src/server.c:3993] -> [src/server.c:3995]: (warning) Either the
>> condition 'nameserver' is redundant or there is possible null pointer
>> dereference: nameserver.
>> [src/ssl_sock.c:4403] -> [src/ssl_sock.c:4397]: (warning) Either the
>> condition '!bind_conf' is redundant or there is possible null pointer
>> dereference: bind_conf.
>>
>>
> Hi,
>
> You're right, there are bugs there. The worst is on the compression
> filter. I attached patches to fix them.
>
> Willy, could you merge it please ? Some of them must be backported in 1.7.
>
> Thanks,
> --
> Christopher Faulet
>

Re: cppcheck finding

[Christopher Faulet]

Le 15/09/2017 à 08:36, Илья Шипицин a écrit :

great, thank for the feedback.

there're few things like that

[src/flt_http_comp.c:926] -> [src/flt_http_comp.c:926]: (warning) Either 
the condition 'txn' is redundant or there is possible null pointer 
dereference: txn.
[src/flt_spoe.c:2765] -> [src/flt_spoe.c:2766]: (warning) Either the 
condition 'ctx==NULL' is redundant or there is possible null pointer 
dereference: ctx.
[src/haproxy.c:568]: (error) Common realloc mistake: 'next_argv' nulled 
but not freed upon failure
[src/server.c:3993] -> [src/server.c:3995]: (warning) Either the 
condition 'nameserver' is redundant or there is possible null pointer 
dereference: nameserver.
[src/ssl_sock.c:4403] -> [src/ssl_sock.c:4397]: (warning) Either the 
condition '!bind_conf' is redundant or there is possible null pointer 
dereference: bind_conf.




Hi,

You're right, there are bugs there. The worst is on the compression 
filter. I attached patches to fix them.


Willy, could you merge it please ? Some of them must be backported in 1.7.

Thanks,
--
Christopher Faulet
>From 362bf07d61b06469bff839886d52db24daa2aa5e Mon Sep 17 00:00:00 2001
From: Christopher Faulet 
Date: Fri, 15 Sep 2017 10:14:43 +0200
Subject: [PATCH 1/5] BUG/MEDIUM: compression: Fix check on txn in
 smp_fetch_res_comp_algo

The check was totally messed up. In the worse case, it led to a crash, when
res.comp_algo sample fetch was retrieved on uncompressed response (with the
compression enabled).

This patch must be backported in 1.7.
---
 src/flt_http_comp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/flt_http_comp.c b/src/flt_http_comp.c
index 64c669d54..4d5332832 100644
--- a/src/flt_http_comp.c
+++ b/src/flt_http_comp.c
@@ -923,7 +923,7 @@ smp_fetch_res_comp_algo(const struct arg *args, struct sample *smp,
 	struct filter *filter;
 	struct comp_state *st;
 
-	if (!(txn || !(txn->rsp.flags & HTTP_MSGF_COMPRESSING)))
+	if (!txn || !(txn->rsp.flags & HTTP_MSGF_COMPRESSING))
 		return 0;
 
 	list_for_each_entry(filter, _flt(smp->strm)->filters, list) {
-- 
2.13.5

>From 30bb79ce1a47666d5d9cd20636e97b7589e34dd7 Mon Sep 17 00:00:00 2001
From: Christopher Faulet 
Date: Fri, 15 Sep 2017 11:39:36 +0200
Subject: [PATCH 2/5] BUG/MINOR: compression: Check response headers before
 http-response rules eval

This is required if we want to use res.comp or res.comp_algo sample fetches in
http-response rules.

This patch must be backported in 1.7.
---
 src/flt_http_comp.c | 30 +-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/src/flt_http_comp.c b/src/flt_http_comp.c
index 4d5332832..0ed252895 100644
--- a/src/flt_http_comp.c
+++ b/src/flt_http_comp.c
@@ -103,6 +103,12 @@ comp_start_analyze(struct stream *s, struct filter *filter, struct channel *chn)
 		st->initialized = 0;
 		st->finished= 0;
 		filter->ctx = st;
+
+		/* Register post-analyzer on AN_RES_WAIT_HTTP because we need to
+		 * analyze response headers before http-response rules execution
+		 * to be sure we can use res.comp and res.comp_algo sample
+		 * fetches */
+		filter->post_analyzers |= AN_RES_WAIT_HTTP;
 	}
 	return 1;
 }
@@ -135,7 +141,8 @@ comp_http_headers(struct stream *s, struct filter *filter, struct http_msg *msg)
 	if (!(msg->chn->flags & CF_ISRESP))
 		select_compression_request_header(st, s, msg);
 	else {
-		select_compression_response_header(st, s, msg);
+		/* Response headers have already been checked in
+		 * comp_http_post_analyze callback. */
 		if (st->comp_algo) {
 			register_data_filter(s, msg->chn, filter);
 			st->hdrs_len = s->txn->rsp.sov;
@@ -147,6 +154,26 @@ comp_http_headers(struct stream *s, struct filter *filter, struct http_msg *msg)
 }
 
 static int
+comp_http_post_analyze(struct stream *s, struct filter *filter,
+		   struct channel *chn, unsigned an_bit)
+{
+	struct http_txn   *txn = s->txn;
+	struct http_msg   *msg = >rsp;
+	struct comp_state *st  = filter->ctx;
+
+	if (an_bit != AN_RES_WAIT_HTTP)
+		goto end;
+
+	if (!strm_fe(s)->comp && !s->be->comp)
+		goto end;
+
+	select_compression_response_header(st, s, msg);
+
+  end:
+	return 1;
+}
+
+static int
 comp_http_data(struct stream *s, struct filter *filter, struct http_msg *msg)
 {
 	struct comp_state *st = filter->ctx;
@@ -768,6 +795,7 @@ struct flt_ops comp_ops = {
 
 	.channel_start_analyze = comp_start_analyze,
 	.channel_end_analyze   = comp_end_analyze,
+	.channel_post_analyze  = comp_http_post_analyze,
 
 	.http_headers  = comp_http_headers,
 	.http_data = comp_http_data,
-- 
2.13.5

>From eef0b960798c3db93923f2c920f27bab6e53286e Mon Sep 17 00:00:00 2001
From: Christopher Faulet 
Date: Fri, 15 Sep 2017 11:51:18 +0200
Subject: [PATCH 3/5] BUG/MINOR: spoe: Don't rely on SPOE ctx in debug message
 when its creation failed

If the SPOE context creation failed, we must not try to use it in the debug
message used to notice the 

Re: Dynamic server name with HAProxy, based on original hostname

[Igor Cicimov]

On Fri, Sep 15, 2017 at 9:25 PM, Ludovic Gasc  wrote:

> Hi,
>
> I imagine that if I have no answer, it's because it isn't possible with
> HAProxy ?
>
> Thanks for your return.
>
>
> 2017-09-10 22:27 GMT+02:00 Ludovic Gasc :
>
>> Hi,
>>
>> I'm trying to reproduce this Nginx configuration with HAProxy:
>> https://memz.co/reverse-proxy-nginx-docker-microservices/
>>
>> Where it's possible to use DNS as dynamic list to proxy to the right
>> server.
>> Our use case isn't container-related, but simply to move easily a
>> customer from a backend server to another one, without to change the
>> HAproxy configuration.
>>
>> The closest feature in HAProxy seems to be option http_proxy, however, no
>> DNS lookup is performed:
>> http://cbonte.github.io/haproxy-dconv/configuration-1.7.
>> html#4.2-option%20http_proxy
>>
>> I have tried to use a resolver in haproxy configuration + in backend
>> section:
>>   server XX %[hdr(host)]: resolvers dns check
>> inter 1000 init-addr last,libc,127.0.0.1
>>
>> However, it doesn't work.
>>
>> Maybe with a lua script it's possible to implement that, but I would
>> prefer to have a simple configuration like with Nginx.
>>
>> Do I missed something ?
>>
>> BTW, thanks for HAProxy, I like a lot this product ;-)
>>
>> Regards.
>> --
>> Ludovic Gasc (GMLudo)
>>
>
>
​This should be a feature in 1.8, which version did you try?​

Re: Dynamic server name with HAProxy, based on original hostname

[Ludovic Gasc]

Hi,

I imagine that if I have no answer, it's because it isn't possible with
HAProxy ?

Thanks for your return.

2017-09-10 22:27 GMT+02:00 Ludovic Gasc :

> Hi,
>
> I'm trying to reproduce this Nginx configuration with HAProxy:
> https://memz.co/reverse-proxy-nginx-docker-microservices/
>
> Where it's possible to use DNS as dynamic list to proxy to the right
> server.
> Our use case isn't container-related, but simply to move easily a customer
> from a backend server to another one, without to change the HAproxy
> configuration.
>
> The closest feature in HAProxy seems to be option http_proxy, however, no
> DNS lookup is performed:
> http://cbonte.github.io/haproxy-dconv/configuration-1.
> 7.html#4.2-option%20http_proxy
>
> I have tried to use a resolver in haproxy configuration + in backend
> section:
>   server XX %[hdr(host)]: resolvers dns check
> inter 1000 init-addr last,libc,127.0.0.1
>
> However, it doesn't work.
>
> Maybe with a lua script it's possible to implement that, but I would
> prefer to have a simple configuration like with Nginx.
>
> Do I missed something ?
>
> BTW, thanks for HAProxy, I like a lot this product ;-)
>
> Regards.
> --
> Ludovic Gasc (GMLudo)
>

Re: cppcheck finding

[Илья Шипицин]

great, thank for the feedback.

there're few things like that

[src/flt_http_comp.c:926] -> [src/flt_http_comp.c:926]: (warning) Either
the condition 'txn' is redundant or there is possible null pointer
dereference: txn.
[src/flt_spoe.c:2765] -> [src/flt_spoe.c:2766]: (warning) Either the
condition 'ctx==NULL' is redundant or there is possible null pointer
dereference: ctx.
[src/haproxy.c:568]: (error) Common realloc mistake: 'next_argv' nulled but
not freed upon failure
[src/server.c:3993] -> [src/server.c:3995]: (warning) Either the condition
'nameserver' is redundant or there is possible null pointer dereference:
nameserver.
[src/ssl_sock.c:4403] -> [src/ssl_sock.c:4397]: (warning) Either the
condition '!bind_conf' is redundant or there is possible null pointer
dereference: bind_conf.


I had a quick look to them, seem to be logical errors.
are there any CI process for haproxy ? I didn't find any


2017-09-15 11:26 GMT+05:00 Willy Tarreau :

> Hello Ilya,
>
> On Thu, Sep 14, 2017 at 11:11:36PM +0500,  ??? wrote:
> > hello,
> >
> > [src/flt_http_comp.c:926] -> [src/flt_http_comp.c:926]: (warning) Either
> > the condition 'txn' is redundant or there is possible null pointer
> > dereference: txn.
> >
> > should there be && instead of || ?
>
> You're speaking about this :
>
> if (!(txn || !(txn->rsp.flags & HTTP_MSGF_COMPRESSING)))
> return 0;
>
> and you're right, it should be this :
>
> if (!txn || !(txn->rsp.flags & HTTP_MSGF_COMPRESSING))
> return 0;
>
> CCing Christopher. We've had this since 1.7 apparently.
>
> Thanks for the report!
> Willy
>

Re: cppcheck finding

[Willy Tarreau]

Hello Ilya,

On Thu, Sep 14, 2017 at 11:11:36PM +0500,  ??? wrote:
> hello,
> 
> [src/flt_http_comp.c:926] -> [src/flt_http_comp.c:926]: (warning) Either
> the condition 'txn' is redundant or there is possible null pointer
> dereference: txn.
> 
> should there be && instead of || ?

You're speaking about this :

if (!(txn || !(txn->rsp.flags & HTTP_MSGF_COMPRESSING)))
return 0;

and you're right, it should be this :

if (!txn || !(txn->rsp.flags & HTTP_MSGF_COMPRESSING))
return 0;

CCing Christopher. We've had this since 1.7 apparently.

Thanks for the report!
Willy