Re: Replicated stick tables have absurd values for conn_cur

[Emerson Gomes]

Hello Tim,

Sorry for the delayed answer.
The segfaults I had experinced apparently were related to something else -
Maybe some issue in my env.
At first I tried to apply the patch to 1.9.0, but after applying it to
1.8.7, I no longer had the segfaults.

So far I yet haven't experienced the underflow issue again.
I think it would be nice to merge this change to next releases - Not sure
how this is managed around here without the tracking tool :)

BR.,
Emerson









Em sáb, 12 de jan de 2019 às 12:34, Tim Düsterhus 
escreveu:

> Emerson,
>
> Am 07.01.19 um 13:40 schrieb Emerson Gomes:
> > Just to update you, I have tried the patch, and while I didnt see any new
> > occurences of the underflow, HAProxy started to crash constantly...
> >
> > Jan 07 10:32:37 afrodite haproxy[14364]: [ALERT] 006/103237 (14364) :
> > Current worker #1 (14366) exited with code 139 (Segmentation fault)
> > Jan 07 10:32:37 afrodite haproxy[14364]: [ALERT] 006/103237 (14364) :
> > exit-on-failure: killing every workers with SIGTERM
> > Jan 07 10:32:37 afrodite haproxy[14364]: [WARNING] 006/103237 (14364) :
> All
> > workers exited. Exiting... (139)
> >
> > I am not sure if the segfaults are related to the patch - Continuing
> > investigation...
> >
>
> I only checked whether my patch compiled successfully, but not whether
> it actually worked. I did not find the time to take a deeper look yet,
> I'm afraid.
>
> Did you find out, whether the segfaults are caused by the patch and
> where exactly it segfaults?
>
> Best regards
> Tim Düsterhus
>

Re: stats webpage crash, htx and scope filter, [PATCH] REGTEST is included

[PiBa-NL]

Hi Christopher,

Op 14-1-2019 om 11:17 schreef Christopher Faulet:

Le 12/01/2019 à 23:23, PiBa-NL a écrit :

Hi List,

I've configured haproxy with htx and when i try to filter the stats 
webpage.

Sending this request: "GET /?;csv;scope=b1" to '2.0-dev0-762475e
2019/01/10' it will crash with the trace below.
1.9.0 and 1.9.1 are also affected.

Can someone take a look? Thanks in advance.

A regtest is attached that reproduces the behavior, and which i think
could be included into the haproxy repository.



Pieter,

Here is the patch that should fix this issue. This was "just" an 
oversight when the stats applet has been adapted to support the HTX.


If it's ok for you, I'll also merge your regtest.

Thanks


It seems the patch did not change/fix the crash.? Below looks pretty 
much the same as previously. Did i fail to apply the patch properly.? It 
seems to have 'applied' properly checking a few lines of the touched 
code manually. As for the regtest, yes please merge that if its okay 
as-is, perhaps after the fix is also ready :).


Regards,
PiBa-NL (Pieter)

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x005658e7 in strnistr (str1=0x802631048 "fe1", len_str1=3, 
str2=0x271dfcc , 
len_str2=3) at src/standard.c:3657

3657    while (toupper(*start) != toupper(*str2)) {
(gdb) bt full
#0  0x005658e7 in strnistr (str1=0x802631048 "fe1", len_str1=3, 
str2=0x271dfcc , 
len_str2=3) at src/standard.c:3657

    pptr = 0x271dfcc 
    sptr = 0x6995d3 "text/plain"
    start = 0x802631048 "fe1"
    slen = 3
    plen = 3
    tmp1 = 0
    tmp2 = 4294958728
#1  0x004d09ff in stats_dump_proxy_to_buffer (si=0x8026416d8, 
htx=0x8027c8e40, px=0x8026b3c00, uri=0x802638000) at src/stats.c:2087
    scope_ptr = 0x271dfcc 0x271dfcc>

    appctx = 0x802678380
    s = 0x802641400
    rep = 0x802641470
    sv = 0x8027c8e40
    svs = 0x343e1e0
    l = 0x4d3a8f 
    flags = 0
#2  0x004d49e9 in stats_dump_stat_to_buffer (si=0x8026416d8, 
htx=0x8027c8e40, uri=0x802638000) at src/stats.c:2664

Question about haproxy.org

[Joe Robinson]

Hi there, 
 
I'm Joe from VPNTeacher.com - we're a new site that aims to change the 
landscape of VPN advice sites by offering the most comprehensive and unbiased 
online privacy advice. Between our small team we have many years experience in 
cybersecurity and online privacy, and are hoping to publish a few high-quality 
articles on sites like yours. 
 
I have some ideas that could work for your site within topics such as PII, 
cryptography, policy, malware and ransomware, etc. and would make it 
appropriate to your audience. 
 
Here are a couple of samples of my writing: 
 
https://www.business2community.com/cybersecurity/how-to-protect-your-business-from-social-engineering-attacks-02152349
 
https://www.bestbackups.com/secure-dropbox/  
https://www.sabaitechnology.com/net-neutrality-the-always-up-to-date-guide/ 
 
If this sounds like something you would be interested in, please let me know 
any author guidelines you have, and a few details about who it should be 
written for, and I'll send over some possible titles. 
 
Many thanks, 
 
Joe 
 
If you don't want to hear from me again, please let me know ( 
http://unsubscribe.bz-mail-us1.com/unsubscribe?e=haproxy%40formilux.org=1399274655.3365352.1547477385344%40ip-10-1-0-82=47277=26489
 )

Re: [PATCH 10/10] DOC: peers: SSL/TLS documentation for "peers"

[Frederic Lecaille]

On 1/14/19 2:56 PM, Willy Tarreau wrote:

Hi Fred,

first, thanks for reviving this!

On Fri, Jan 11, 2019 at 02:52:24PM +0100, flecai...@haproxy.com wrote:

+bind [param*]
+  Defines the binding parameters of the local peer of this "peers" section.
+  To avoid some redundancy, and as the  and  parameters
+  are already provided on "peer" (or "server") lines, they are not supported
+  by "bind" keyword in "peers" sections.
+

(...)

+   Example:
+ peers mypeers
+ bind ssl crt mycerts/pem
+ default-server ssl verify none
+ server hostA  127.0.0.10:1
+ server hostB  127.0.0.11:10001


Just thinking loud, I find this a bit confusing : "bind" usually is
followed by an address to bind to. And it's even wider than just the
haproxy culture. Here from what I'm seeing you're using it exactly
like "default-server", i.e. you can pass all default settings but not
the address. Thus I think that having a "default-bind" directive would
remove this confusion.


+  Note: "peer" keyword may transparently be replaced by "server" keyword (see
+  "server" keyword explanation below).
+
+server  : [param*]
+  As previously mentionned, "peer" keyword may be replaced by "server" keyword
+  with a support for all "server" parameters found in 5.2 paragraph.
+  Some of these parameters are irrelevant for "peers" sections.


Same here, if "server" also creates a listening address, it's quite
confusing in my opinion.


Yes, this is because the "peers" configuration are supposed to be
duplicated without on each haproxy peer. I agree that
"server" should only means "remote peer". It is confusing for the local
peer. Peers are remote or local, contrary to servers which are only
remote peers.


And this makes me think a bit further. I remember some old discussions
where we were saying that the main problem posed by peers is that they
are forcibly symmetrical ; you cannot use them on a dynamic IP address
or on a set of IP addresses for example because you are not allowed to
put 0.0.0.0 here as it also serves as a destination address. You cannot
use a unix socket nor 127.0.0.1 either, just like it's not possible to
listen both to IPv4 and IPv6 addresses.


yes, the peers section configurations are identical on each peer 
belonging to the section.



And I think that your "bind" + "server" options could solve this in a
very elegant way : what about having "bind" always set the listening
address and "server" always set only the target address ? In this case
we could simply handle the migration by making it an error to have both
"bind" and "peer". And thinking about it, I feel like that's a discussion
we already had in the past.


Ok.


Thus I think we could end up with this :

First step :
   - "peer" does what it currently does, i.e. set both the bind and the
  target address ;
   - "default-server" applies to the server part of the peers
   - "default-bind" applies to the bind part of the peers
   => that's what you did modulo the last option's naming

Then we add this :
   - "bind" only sets the bind address and bind options ;
   - "server" only sets target addresses and server options ;

And this will also solve the problem of testing peers with vtest, since
this time they will work *exactly* like real bind+servers with their own
addresses :-)

What do you think ?


I think that all this makes sense as always ;)
I will send a new series of patches for these modifications asap.

Re: [PATCH 10/10] DOC: peers: SSL/TLS documentation for "peers"

[Willy Tarreau]

Hi Fred,

first, thanks for reviving this!

On Fri, Jan 11, 2019 at 02:52:24PM +0100, flecai...@haproxy.com wrote:
> +bind [param*]
> +  Defines the binding parameters of the local peer of this "peers" section.
> +  To avoid some redundancy, and as the  and  parameters
> +  are already provided on "peer" (or "server") lines, they are not supported
> +  by "bind" keyword in "peers" sections.
> +
(...)
> +   Example:
> + peers mypeers
> + bind ssl crt mycerts/pem
> + default-server ssl verify none
> + server hostA  127.0.0.10:1
> + server hostB  127.0.0.11:10001

Just thinking loud, I find this a bit confusing : "bind" usually is
followed by an address to bind to. And it's even wider than just the
haproxy culture. Here from what I'm seeing you're using it exactly
like "default-server", i.e. you can pass all default settings but not
the address. Thus I think that having a "default-bind" directive would
remove this confusion.

> +  Note: "peer" keyword may transparently be replaced by "server" keyword (see
> +  "server" keyword explanation below).
> +
> +server  : [param*]
> +  As previously mentionned, "peer" keyword may be replaced by "server" 
> keyword
> +  with a support for all "server" parameters found in 5.2 paragraph.
> +  Some of these parameters are irrelevant for "peers" sections.

Same here, if "server" also creates a listening address, it's quite
confusing in my opinion.

And this makes me think a bit further. I remember some old discussions
where we were saying that the main problem posed by peers is that they
are forcibly symmetrical ; you cannot use them on a dynamic IP address
or on a set of IP addresses for example because you are not allowed to
put 0.0.0.0 here as it also serves as a destination address. You cannot
use a unix socket nor 127.0.0.1 either, just like it's not possible to
listen both to IPv4 and IPv6 addresses.

And I think that your "bind" + "server" options could solve this in a
very elegant way : what about having "bind" always set the listening
address and "server" always set only the target address ? In this case
we could simply handle the migration by making it an error to have both
"bind" and "peer". And thinking about it, I feel like that's a discussion
we already had in the past.

Thus I think we could end up with this :

First step :
  - "peer" does what it currently does, i.e. set both the bind and the
 target address ;
  - "default-server" applies to the server part of the peers
  - "default-bind" applies to the bind part of the peers
  => that's what you did modulo the last option's naming

Then we add this :
  - "bind" only sets the bind address and bind options ;
  - "server" only sets target addresses and server options ;

And this will also solve the problem of testing peers with vtest, since
this time they will work *exactly* like real bind+servers with their own
addresses :-)

What do you think ?

Thanks,
Willy

Re: [PATCH 0/2] Switch to vtest.

[Willy Tarreau]

Hi Fred,

On Fri, Jan 11, 2019 at 10:10:20AM +0100, flecai...@haproxy.com wrote:
> From: Frédéric Lécaille 
> 
> Hi ML,
> 
> With these patches, haproxy switches to the new varnish cache reg testing tool
> named vtest, formerly known as varnishtest.
> 
> From the user point of view, there is no very much differences compared to the
> usage of varnishtest. Before we started the reg testing process as follows:
> 
>$ VARNISTEST_PROGRAM=<...> make reg-tests
> 
> now we have to run:
> 
>$ VTEST_PROGRAM=<...> make reg-tests

I also think it's still time to change this before everyone starts to use
it indeed, especially since early adopters are quite autonomous on this.
I nobody objects I'd like to backport this to 1.9 as well so that we keep
the same reg-testing suite.

If someone has issues with the variable name change due to already
deployed tools, we could keep the two and have VTEST_PROGRAM default to
VARNISHTEST_PROGRAM.

Anyway now that's merged into master.

Thanks,
Willy

Re: Get client IP

[Aleksandar Lazic]

Hi.

Am 14.01.2019 um 03:11 schrieb Vũ Xuân Học:
> Hi,
> 
>  
> 
> I don’t know how to use ssl in http mode. I have many site with many 
> certificate.
> 
> As you see:
> 
> …
> 
> bind 192.168.0.4:443   (I NAT port 443 from firewall to HAProxy IP 
> 192.168.0.4)
> 
> …
> 
> # Define hosts
> 
>     acl host_1 req.ssl_sni -i ebh.vn
> 
>     acl host_2 req.ssl_sni hdr_end(host) -i einvoice.com.vn
> 
>     … (many acl like above)
> 
> 
>     use_backend eBH if host_1
> 
>    use_backend einvoice443 if host_2

You can use maps for this.
https://www.haproxy.com/blog/introduction-to-haproxy-maps/

The openshift router have a complex but usable solution. Don't get confused with
the golang template stuff in there.

https://github.com/openshift/router/blob/master/images/router/haproxy/conf/haproxy-config.template#L180

https://github.com/openshift/router/blob/master/images/router/haproxy/conf/haproxy-config.template#L198

Regards
Aleks

> *From:* Aleksandar Lazic 
> *Sent:* Monday, January 14, 2019 8:45 AM
> *To:* haproxy@formilux.org; Vũ Xuân Học ; 'PiBa-NL'
> 
> *Subject:* RE: Get client IP
> 
>  
> 
> Hi.
> 
> As you use IIS I strongly suggest to terminate the https on haproxy and use 
> mode
> http instead of tcp.
> 
> Here is a blog post about basic setup of haproxy with ssl
> 
> https://www.haproxy.com/blog/how-to-get-ssl-with-haproxy-getting-rid-of-stunnel-stud-nginx-or-pound/
> 
> I assume that haproxy have the client ip as the setup works in the http 
> config.
> 
> Best regards
> Aleks
> 
> 
> 
> *Von:*"Vũ Xuân Học" mailto:ho...@thaison.vn>>
> *Gesendet:* 14. Jänner 2019 02:17:23 MEZ
> *An:* 'PiBa-NL' mailto:piba.nl@gmail.com>>,
> 'Aleksandar Lazic' mailto:al-hapr...@none.at>>,
> haproxy@formilux.org 
> *Betreff:* RE: Get client IP
> 
>  
> 
> Thanks for your help
> 
>  
> 
> I try config HAProxy with accept-proxy like this:
> 
> frontend ivan
> 
>  
> 
>     bind 192.168.0.4:443 accept-proxy
> 
>     mode tcp
> 
>     option tcplog
> 
>  
> 
> #option forwardfor
> 
>  
> 
>     reqadd X-Forwarded-Proto:\ https
> 
>  
> 
> then my website can not access.
> 
> I use IIS as webserver and I don’t know how to accept proxy, I only know 
> config
> X-Forwarded-For like this
> 
> http://www.loadbalancer.org/blog/iis-and-x-forwarded-for-header/
> 
>  
> 
>  
> 
> *From:* PiBa-NL mailto:piba.nl@gmail.com>>
> *Sent:* Sunday, January 13, 2019 10:06 PM
> *To:* Aleksandar Lazic mailto:al-hapr...@none.at>>; Vũ 
> Xuân
> Học mailto:ho...@thaison.vn>>; haproxy@formilux.org
> 
> *Subject:* Re: Get client IP
> 
>  
> 
> Hi,
> 
> Op 13-1-2019 om 13:11 schreef Aleksandar Lazic:
> 
> Hi.
> 
>  
> 
> Am 13.01.2019 um 12:17 schrieb Vũ Xuân Học:
> 
> Hi,
> 
>  
> 
> Please help me to solve this problem.
> 
>  
> 
> I use HAProxy version 1.5.18, SSL transparent mode and I can not get 
> client IP
> 
> in my .net mvc website. With mode http, I can use option forwardfor 
> to catch
> 
> client ip but with tcp mode, my web read X_Forwarded_For is null.
> 
>  
> 
>  
> 
>  
> 
> My diagram:
> 
>  
> 
> Client => Firewall => HAProxy => Web
> 
>  
> 
>  
> 
>  
> 
> I read HAProxy document, try to use send-proxy. But when use 
> send-proxy, I can
> 
> access my web.
> 
>  
> 
> This is my config:
> 
>  
> 
> frontend test2233
> 
>  
> 
>     bind *:2233
> 
>  
> 
>     option forwardfor
> 
>  
> 
>  
> 
>  
> 
>     default_backend testecus
> 
>  
> 
> backend testecus
> 
>  
> 
>     mode http
> 
>  
> 
>     server web1 192.168.0.151:2233 check
> 
>  
> 
> Above config work, and I can get the client IP
> 
>  
> 
> That's good as it's `mode http` therefore haproxy can see the http 
> traffic.
> 
> Indeed it can insert the http forwardfor header with 'mode http'.
> 
>  
> 
>  
> 
> Config with SSL:
> 
>  
> 
> frontend ivan
> 
>  
> 
>     bind 192.168.0.4:443
> 
>     mode tcp
> 
>     option tcplog
> 
>  
> 
> #option forwardfor
> 
>  
> 
>     reqadd X-Forwarded-Proto:\ https
> 
>  
> 
> This can't work as you use `mode tcp` and therefore haproxy can't see the 
> http
> 
> traffic.
> 
>  
> 
> From my point of view have you now 2 options.
> 
>  
> 
> * use https termination on haproxy. Then you can add this http header.
> 
> Thats one option indeed.
> 
>  
> 
> * use accept-proxy in the bind line. This option requires that the 
> firewall is
> 
> able to send the PROXY 

Re: stats webpage crash, htx and scope filter, [PATCH] REGTEST is included

[Christopher Faulet]

Le 12/01/2019 à 23:23, PiBa-NL a écrit :

Hi List,

I've configured haproxy with htx and when i try to filter the stats webpage.
Sending this request: "GET /?;csv;scope=b1" to '2.0-dev0-762475e
2019/01/10' it will crash with the trace below.
1.9.0 and 1.9.1 are also affected.

Can someone take a look? Thanks in advance.

A regtest is attached that reproduces the behavior, and which i think
could be included into the haproxy repository.



Pieter,

Here is the patch that should fix this issue. This was "just" an 
oversight when the stats applet has been adapted to support the HTX.


If it's ok for you, I'll also merge your regtest.

Thanks
--
Christopher Faulet
>From d09c87cf3d261b42f02671b3ddf2cbc36b7e1916 Mon Sep 17 00:00:00 2001
From: Christopher Faulet 
Date: Mon, 14 Jan 2019 11:07:34 +0100
Subject: [PATCH] BUG/MEDIUM: stats: Get the rigth scope pointer depending on
 HTX is used or not

For HTX streams, the scope pointer is relative to the TXN uri. But for streams
using the legacy HTTP representation, the scope pointer is relative to the
beginning of output data in the channel's buffer. So we must be carefull to use
the right one depending on the HTX is used or not.

Thanks to Pieter (PiBa-NL) to report this bug.

This patch must be backported to 1.9.
---
 src/stats.c | 26 +++---
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/src/stats.c b/src/stats.c
index ebd95d3f0..ee375af6f 100644
--- a/src/stats.c
+++ b/src/stats.c
@@ -1912,8 +1912,12 @@ static void stats_dump_html_px_hdr(struct stream_interface *si, struct proxy *px
 		/* scope_txt = search pattern + search query, appctx->ctx.stats.scope_len is always <= STAT_SCOPE_TXT_MAXLEN */
 		scope_txt[0] = 0;
 		if (appctx->ctx.stats.scope_len) {
+			char *scope_ptr = (IS_HTX_STRM(si_strm(si))
+	   ? si_strm(si)->txn->uri  + appctx->ctx.stats.scope_str
+	   : co_head(si_oc(si))  + appctx->ctx.stats.scope_str);
+
 			strcpy(scope_txt, STAT_SCOPE_PATTERN);
-			memcpy(scope_txt + strlen(STAT_SCOPE_PATTERN), co_head(si_oc(si)) + appctx->ctx.stats.scope_str, appctx->ctx.stats.scope_len);
+			memcpy(scope_txt + strlen(STAT_SCOPE_PATTERN), scope_ptr, appctx->ctx.stats.scope_len);
 			scope_txt[strlen(STAT_SCOPE_PATTERN) + appctx->ctx.stats.scope_len] = 0;
 		}
 
@@ -2075,9 +2079,14 @@ int stats_dump_proxy_to_buffer(struct stream_interface *si, struct htx *htx,
 		/* if the user has requested a limited output and the proxy
 		 * name does not match, skip it.
 		 */
-		if (appctx->ctx.stats.scope_len &&
-		strnistr(px->id, strlen(px->id), co_head(si_oc(si)) + appctx->ctx.stats.scope_str, appctx->ctx.stats.scope_len) == NULL)
-			return 1;
+		if (appctx->ctx.stats.scope_len) {
+			char *scope_ptr = (IS_HTX_STRM(si_strm(si))
+	   ? si_strm(si)->txn->uri  + appctx->ctx.stats.scope_str
+	   : co_head(si_oc(si))  + appctx->ctx.stats.scope_str);
+
+			if (strnistr(px->id, strlen(px->id), scope_ptr, appctx->ctx.stats.scope_len) == NULL)
+return 1;
+		}
 
 		if ((appctx->ctx.stats.flags & STAT_BOUND) &&
 		(appctx->ctx.stats.iid != -1) &&
@@ -2347,6 +2356,9 @@ static void stats_dump_html_info(struct stream_interface *si, struct uri_auth *u
 	struct appctx *appctx = __objt_appctx(si->end);
 	unsigned int up = (now.tv_sec - start_date.tv_sec);
 	char scope_txt[STAT_SCOPE_TXT_MAXLEN + sizeof STAT_SCOPE_PATTERN];
+	char *scope_ptr = (IS_HTX_STRM(si_strm(si))
+			   ? si_strm(si)->txn->uri  + appctx->ctx.stats.scope_str
+			   : co_head(si_oc(si))  + appctx->ctx.stats.scope_str);
 
 	/* WARNING! this has to fit the first packet too.
 	 * We are around 3.5 kB, add adding entries will
@@ -2405,7 +2417,7 @@ static void stats_dump_html_info(struct stream_interface *si, struct uri_auth *u
 	  );
 
 	/* scope_txt = search query, appctx->ctx.stats.scope_len is always <= STAT_SCOPE_TXT_MAXLEN */
-	memcpy(scope_txt, co_head(si_oc(si)) + appctx->ctx.stats.scope_str, appctx->ctx.stats.scope_len);
+	memcpy(scope_txt, scope_ptr, appctx->ctx.stats.scope_len);
 	scope_txt[appctx->ctx.stats.scope_len] = '\0';
 
 	chunk_appendf(,
@@ -2417,7 +2429,7 @@ static void stats_dump_html_info(struct stream_interface *si, struct uri_auth *u
 	scope_txt[0] = 0;
 	if (appctx->ctx.stats.scope_len) {
 		strcpy(scope_txt, STAT_SCOPE_PATTERN);
-		memcpy(scope_txt + strlen(STAT_SCOPE_PATTERN), co_head(si_oc(si)) + appctx->ctx.stats.scope_str, appctx->ctx.stats.scope_len);
+		memcpy(scope_txt + strlen(STAT_SCOPE_PATTERN), scope_ptr, appctx->ctx.stats.scope_len);
 		scope_txt[strlen(STAT_SCOPE_PATTERN) + appctx->ctx.stats.scope_len] = 0;
 	}
 
@@ -3136,7 +3148,7 @@ static int stats_send_htx_redirect(struct stream_interface *si, struct htx *htx)
 	scope_txt[0] = 0;
 	if (appctx->ctx.stats.scope_len) {
 		strcpy(scope_txt, STAT_SCOPE_PATTERN);
-		memcpy(scope_txt + strlen(STAT_SCOPE_PATTERN), co_head(si_oc(si)) + appctx->ctx.stats.scope_str, appctx->ctx.stats.scope_len);
+		memcpy(scope_txt + strlen(STAT_SCOPE_PATTERN), s->txn->uri + 

Re: [RFC PATCH] couple of reg-tests

[Christopher Faulet]

Le 09/01/2019 à 15:42, Frederic Lecaille a écrit :

On 1/9/19 3:22 PM, Jarno Huuskonen wrote:

Hello Frederic,

On Mon, Jan 07, Frederic Lecaille wrote:


reg-tests/http-rules/h3.vtc fails on my side due to a typo in
the regex with this error:

 h10.0 CLI regexp error: 'missing opening brace after \o'
(@48) (^0x[a-f0-9]+ example\.org
https://www\.example.\org\n0x[a-f0-9]+ subdomain\.example\.org
https://www\.subdomain\.example\.org\n$)

.\org shoulb be replaced by \.org

Could you check on your side why you did not notice this issue please?


For some reason the buggy regex works for me, maybe it depends on
pcre version.
My varnishtest links to centos7 default pcre (pcre-8.32-17.el7.x86_64).


Not that weird. This POSIX is not supported

   9.3.2 BRE Ordinary Characters

An ordinary character is a BRE that matches itself: any character in the
supported character set, except for the BRE special characters listed in
BRE Special Characters.

The interpretation of an ordinary character preceded by a backslash (
'\' ) is undefined, except for:

  The characters ')', '(', '{', and '}'

  The digits 1 to 9 inclusive (see BREs Matching Multiple Characters)

  A character inside a bracket expression

http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap09.html


After checking this issue we will merge your patches. Great work!


I'm attaching the patches again, with fixed regex in h3.vtc.
The patches are for recent 2.0dev.

Should reg-tests/README default to [-Dno-htx='#'] instead of -Dno-htx= ?


Perhaps [-Dno-htx=[#]] is even better as the # here is optional? I do
not care on my side.

Do not modify anymore your patch for that.

Anybody to merge Jarno's patches?

Thank you for replying Jarno.



Thanks guys, now merged !

--
Christopher Faulet

RE: Haproxy using 100% CPU - mostly epoll call

[Basha Mougamadou]

Hello Willy,

> Hello Basha,

> On Wed, Jan 09, 2019 at 01:16:18PM +, Basha Mougamadou wrote:
>> Hello,
>> 
>> Using haproxy 1.8.16-5c3f237, for unknown reason, one of the process uses 
>> all the available cores.
>> 
>>PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
>>  25120 haproxy   20   0  813808 212372   7268 R 799.3  0.3   1222:23 haproxy
>>  26653 haproxy   20   0  814916 214880   6044 S   1.7  0.3   2:12.09 haproxy
>> 
>> As of now, the process is still running, haven't killed it for the sake of 
>> debugging the issue.
>> 
>> With the debug info below, do you have some ideas on why/how this occurs?

> It's been a while since we've last had such issues. If the process still 
> works, could you please issue the following commands to the CLI ?
>  "show activity"
>  "show fd"
>  "show info"
>  "show sess all"

Unfortunately, the process got restarted.
Thanks for the commands, will keep that in mind for when/if it happens again.

Cheers,
-- Basha

Re: stats webpage crash, htx and scope filter, [PATCH] REGTEST is included

[Christopher Faulet]

Le 12/01/2019 à 23:23, PiBa-NL a écrit :

Hi List,

I've configured haproxy with htx and when i try to filter the stats webpage.
Sending this request: "GET /?;csv;scope=b1" to '2.0-dev0-762475e
2019/01/10' it will crash with the trace below.
1.9.0 and 1.9.1 are also affected.

Can someone take a look? Thanks in advance.


Hi Pieter,

I'm on it. Thanks

--
Christopher Faulet