Re: 'set-dst' and 'set-dst-port' tcp/http actions
On Wed, Jun 01, 2016 at 12:01:45AM +0200, William Lallemand wrote:
> Hello,
>
> Here a set of patches implementing http/tcp set-{dst,src}[-port].
>
> The feature can be useful to connect to a IP/port which is defined in a map.
Merged, thank you William.
I'm seeing that set-src/set-dst force the port to zero by default and
that it is what we used to have already in 1.6. I think it would have
been better to preserve the original value, in order to let src and
src-port be preformed in any order, but I guess we decided on forcing
to zero in 1.6 just because there was no action to set the port :-/
Maybe that's something we can change in 1.7 if nobody objects, as it
would make it more obvious what a configuration does (though the doc
is pretty clear about it).
Willy
http://www.haproxy.org/download/contrib/ appears out of date
Hi, Just a quick note to mention that the data found at http://www.haproxy.org/download/contrib/ appears to be out of date, when compared with the current state of Git, or recent releases. Also, interestingly, the directory listing at: http://www.haproxy.org/download/contrib/netsnmp-perl/ does not list the file: http://www.haproxy.org/download/contrib/netsnmp-perl/README Charlie
Re: Lua converter not working in 1.6.5 with Lua 5.3.2
Hi Willy, I join a serie of 3 patches. With these patches, I can't reproduce the bug. Michael, can you test the patches and confirm or not that the bug disappear ? All the patches must be backported in the 1.6 version, an onr of these must be also backported in the 1.5 version. Thierry On Mon, 30 May 2016 16:29:37 +0200 Willy Tarreau wrote: > On Mon, May 30, 2016 at 04:26:11PM +0200, Thierry FOURNIER wrote: > > Thank you for the bug report; > > > > I catch it. I join a temporary fix, I suspect that the problem to be more > > tricky. > > Thierry, just to be clear, I preferred not to pick your patches for now > since you're still debugging. However if you think that I should take > them anyway because they already fix known issues, just tell me so and > I'll pick them. > > thanks, > Willy --
Re: Lua converter not working in 1.6.5 with Lua 5.3.2
I forgot the patches in attachment ;)
On Wed, 1 Jun 2016 14:03:51 +0200
Thierry FOURNIER wrote:
> Hi Willy,
>
> I join a serie of 3 patches. With these patches, I can't reproduce the
> bug.
>
> Michael, can you test the patches and confirm or not that the bug
> disappear ?
>
> All the patches must be backported in the 1.6 version, an onr of these
> must be also backported in the 1.5 version.
>
> Thierry
>
>
> On Mon, 30 May 2016 16:29:37 +0200
> Willy Tarreau wrote:
>
> > On Mon, May 30, 2016 at 04:26:11PM +0200, Thierry FOURNIER wrote:
> > > Thank you for the bug report;
> > >
> > > I catch it. I join a temporary fix, I suspect that the problem to be more
> > > tricky.
> >
> > Thierry, just to be clear, I preferred not to pick your patches for now
> > since you're still debugging. However if you think that I should take
> > them anyway because they already fix known issues, just tell me so and
> > I'll pick them.
> >
> > thanks,
> > Willy
>
>
> --
>
>
--
>From 3cbde733f4a8c5a2af574d875090eb465ddba9fe Mon Sep 17 00:00:00 2001
From: Thierry Fournier
Date: Wed, 1 Jun 2016 13:36:20 +0200
Subject: [PATCH 2/3] BUG/MINOR: http: add-header: header name copied two times
The header name is copied two time in the buffer. The first copy is a printf-like
function writing the name and the http separators in the buffer, and the second
form is a memcopy. This seems to be inherited from some changes. This patch
removes the printf like, format.
This patch must be backported in 1.6 and 1.5 versions
---
src/proto_http.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/proto_http.c b/src/proto_http.c
index 6686631..d32acb0 100644
--- a/src/proto_http.c
+++ b/src/proto_http.c
@@ -3401,7 +3401,6 @@ resume_execution:
case ACT_HTTP_SET_HDR:
case ACT_HTTP_ADD_HDR:
- chunk_printf(&trash, "%s: ", rule->arg.hdr_add.name);
memcpy(trash.str, rule->arg.hdr_add.name, rule->arg.hdr_add.name_len);
trash.len = rule->arg.hdr_add.name_len;
trash.str[trash.len++] = ':';
--
2.1.4
>From 886a6934256ce77f6fb9b88df3f7a0fda9cc7a6f Mon Sep 17 00:00:00 2001
From: Thierry Fournier
Date: Wed, 1 Jun 2016 13:35:36 +0200
Subject: [PATCH 3/3] BUG/MEDIUM: http: add-header: buffer overwritted
If we use the action "http-request add-header" with a Lua sample-fetch or
converter, and the Lua function calls one of the Lua log function, the
header name is corrupted, it contains an extract of the last loggued data.
This is due to an overwrite of the trash buffer, because his scope is not
respected in the "add-header" function. The scope of the trash buffer must
be limited to the function using it. The build_logline() function can
execute a lot of other function which can use the trash buffer.
This patch fix the usage of the trash buffer. It limits the scope of this
global buffer to the local function, we build first the header value using
build_logline, and after we store the header name.
Thanks Michael Ezzell for the repporting.
This patch must be backported in 1.6 version
---
src/proto_http.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/src/proto_http.c b/src/proto_http.c
index d32acb0..3ca456e 100644
--- a/src/proto_http.c
+++ b/src/proto_http.c
@@ -3290,6 +3290,7 @@ http_req_get_intercept_rule(struct proxy *px, struct list *rules, struct stream
struct hdr_ctx ctx;
const char *auth_realm;
int act_flags = 0;
+ int len;
/* If "the current_rule_list" match the executed rule list, we are in
* resume condition. If a resume is needed it is always in the action
@@ -3401,11 +3402,18 @@ resume_execution:
case ACT_HTTP_SET_HDR:
case ACT_HTTP_ADD_HDR:
+ /* The scope of the trash buffer must be limited to this function. The
+ * build_logline() function can execute a lot of other function which
+ * can use the trash buffer. So for limiting the scope of this global
+ * buffer, we build first the header value using build_logline, and
+ * after we store the header name.
+ */
+ len = rule->arg.hdr_add.name_len + 2,
+ len += build_logline(s, trash.str + len, trash.size - len, &rule->arg.hdr_add.fmt);
memcpy(trash.str, rule->arg.hdr_add.name, rule->arg.hdr_add.name_len);
- trash.len = rule->arg.hdr_add.name_len;
- trash.str[trash.len++] = ':';
- trash.str[trash.len++] = ' ';
- trash.len += build_logline(s, trash.str + trash.len, trash.size - trash.len, &rule->arg.hdr_add.fmt);
+ trash.str[rule->arg.hdr_add.name_len] = ':';
+ trash.str[rule->arg.hdr_add.name_len + 1] = ' ';
+ trash.len = len;
if (rule->action == ACT_HTTP_SET_HDR) {
/* remove all occurrences of the header */
--
2.1.4
>From 06e8d3eec25570ba2909998dd529397a6d2272f2 Mon Sep 17 00:00:00 2001
From: Thierry Fournier
Date: Fri, 27 May 2016 16:35:01 +0200
Subject: [PATCH 1/3] BUG/MEDIUM: lua: converters doesn't work
The number of arguments pushed in the stack are false, so we try to execute a
function out of the stack. This function is always a ni
Re: http://www.haproxy.org/download/contrib/ appears out of date
Hi Charlie, On Wed, Jun 01, 2016 at 11:46:43AM +0100, Charlie Smurthwaite wrote: > Hi, > > Just a quick note to mention that the data found at > http://www.haproxy.org/download/contrib/ appears to be out of date, when > compared with the current state of Git, or recent releases. > > Also, interestingly, the directory listing at: > http://www.haproxy.org/download/contrib/netsnmp-perl/ > > does not list the file: > http://www.haproxy.org/download/contrib/netsnmp-perl/README In fact it's not out of date, it's not updated and frozen in time. I should probably add a warning there that these files are very old. I used to know some people using them, I don't know if it's still the case. thanks, Willy
Re: http://www.haproxy.org/download/contrib/ appears out of date
On 01/06/16 14:03, Willy Tarreau wrote: In fact it's not out of date, it's not updated and frozen in time. I should probably add a warning there that these files are very old. I used to know some people using them, I don't know if it's still the case. thanks, Willy I found them by accident (from Google IIRC) and started using them before I realised they were outdated. A warning seems like a good idea (although I'm not sure where it would go). Alternatively, could the whole tree be redirected to a live Git version, or just deleted :) Charlie
HAProxy Tech will give away some free alohas
Hi all, I hate to abuse the list's bandwidth for anything in relation with a commercial activity, but we have some students and interns here on the list, so they might be interested. HAProxy Technologies will give away a bunch of free ALOHA Pocket (tiny hardware load balancers) for educational purposes. More details here : http://blog.haproxy.com/ /end-of-self-promotion-of-a-fun-project :-) Willy
Re: problems with req.ssl_ec_ext
Hi Pavlos, On Tue, May 31, 2016 at 12:06:14PM +0200, Pavlos Parissis wrote: > > On 30/05/2016 05:24 , Nenad Merdanovic wrote: > > Hello Bjorn, > > > > On 5/30/2016 4:29 PM, Björn Zettergren wrote: > >> Hi, > >> > >> I've been playing around with the ECC+RSA certificate on same IP as > >> described in the haproxy blog at > >> http://blog.haproxy.com/2015/07/15/serving-ecc-and-rsa-certificates-on-same-ip-with-haproxy/ > >> > >> However, I get unexpected results when testing and I'm thinking that > >> my problem is with the sample fetching of req.ssl_ec_ext on incoming > >> requests being inconsistent or haproxy starts processing the request > >> before enough of the data has been sent. I don't know how to > >> troubleshoot any further or how to get it working, if it's at all > >> expected to work "as advertised". > > > > Yes, it seems like the case is that the fetch is only called once, when > > there is not enough data in the buffer. You can work around this like: > > tcp-request inspect-delay 5s > > That option was never clear to me what it does. > Does it introduce a delay on user's request? > I think it only delays the inspection of the request from haproxy > but the actual request isn't delayed. > > Am I right? That's more or less it. Just to make it very clear, it tells haproxy that when facing *incomplete* data preventing it from taking a decision, it should wait this long. What's important to know is that ACLs implement a three-state match : - does not match - does match - uncertain, need more info If you're waiting for a TLS hello and someone sends an HTTP request, it will immediately not match so there is no delay. If someone sends a valid TLS hello message that haproxy can fully parse, there's no delay either. But if the data start like a TLS hello but are incomplete (eg due to a packet loss causing a retransmission), you want haproxy to wait a bit. This tells how long to wait. Past this delay, the pattern doesn't match. That's exactly similar to the http-request timeout for HTTP in fact. Cheers, Willy
Re: problems with req.ssl_ec_ext
On 01/06/2016 03:19 μμ, Willy Tarreau wrote: > Hi Pavlos, > > On Tue, May 31, 2016 at 12:06:14PM +0200, Pavlos Parissis wrote: >> >> On 30/05/2016 05:24 , Nenad Merdanovic wrote: >>> Hello Bjorn, >>> >>> On 5/30/2016 4:29 PM, Björn Zettergren wrote: Hi, I've been playing around with the ECC+RSA certificate on same IP as described in the haproxy blog at http://blog.haproxy.com/2015/07/15/serving-ecc-and-rsa-certificates-on-same-ip-with-haproxy/ However, I get unexpected results when testing and I'm thinking that my problem is with the sample fetching of req.ssl_ec_ext on incoming requests being inconsistent or haproxy starts processing the request before enough of the data has been sent. I don't know how to troubleshoot any further or how to get it working, if it's at all expected to work "as advertised". >>> >>> Yes, it seems like the case is that the fetch is only called once, when >>> there is not enough data in the buffer. You can work around this like: >>> tcp-request inspect-delay 5s >> >> That option was never clear to me what it does. >> Does it introduce a delay on user's request? >> I think it only delays the inspection of the request from haproxy >> but the actual request isn't delayed. >> >> Am I right? > > That's more or less it. Just to make it very clear, it tells haproxy that > when facing *incomplete* data preventing it from taking a decision, it > should wait this long. What's important to know is that ACLs implement a > three-state match : > - does not match > - does match > - uncertain, need more info > > If you're waiting for a TLS hello and someone sends an HTTP request, > it will immediately not match so there is no delay. If someone sends a > valid TLS hello message that haproxy can fully parse, there's no delay > either. But if the data start like a TLS hello but are incomplete (eg > due to a packet loss causing a retransmission), you want haproxy to > wait a bit. This tells how long to wait. Past this delay, the pattern > doesn't match. > > That's exactly similar to the http-request timeout for HTTP in fact. > OK now it is very clear to me how it works. Thanks for the explanation, Pavlos signature.asc Description: OpenPGP digital signature
