Re: [EXTERNAL] [PATCH] MINOR haproxy switching to sched_setaffinity on FreeBSD 14
On Thu, Jan 06, 2022 at 06:57:36PM +, David CARLIER wrote: > Hi here a little patch proposal. Looks good, applied, thank you David! Willy
SV: SV: Troubles with AND in acl
Hi Tim
What is best practis HAProxy?
I have multiple test of the type
http-request set-var(txn.xmail_eas) bool(1) if XMail { url_beg -i
/microsoft-server-activesync }
Do I do all the test and at the end for the frontend block
Make the http-request tarpit if { var(txn.xmail_eas || txn.xmail_xxx) -m bool }
Or should I do a
http-request tarpit if { var(txn.xmail_eas) -m bool }
for each test and exit from the frontend block from there.
Normally when I code in c/c++ I prefere only to have one return in the
procedure, but what is best way in HAProxy because I will make a lot of
unnecessary test.
Also will a http-request tarpit if { var(txn.xmail_eas ) -m bool }
Work like a return so it exit from the frontend?
Regards
Henning
-Oprindelig meddelelse-
Fra: Tim Düsterhus
Sendt: 2. januar 2022 17:04
Til: Henning Svane ; Aleksandar Lazic ;
haproxy@formilux.org
Emne: Re: SV: Troubles with AND in acl
Henning,
On 1/2/22 4:00 PM, Henning Svane wrote:
> This can be parsed
> acl XMail_EAS url_beg -i /microsoft-server-activesync && XMail but
> this will not acl XMail_EAS XMail && url_beg -i
> /microsoft-server-activesync error detected while parsing ACL
> 'XMail_EAS' : unknown fetch method 'XMail' in ACL expression 'XMail'.
HAProxy does not support logical conjunctions within an ACL definition.
You can use a variable as a workaround:
http-request set-var(txn.xmail_eas) bool(1) if XMail { url_beg -i
/microsoft-server-activesync } http-request tarpit if { var(txn.xmail_eas) -m
bool }
Best regards
Tim Düsterhus
Re: Is "http-request del-header" case sensitive?
Shawn, On 1/6/22 10:31 PM, Shawn Heisey wrote: Trying to find out if "http-request del-header" is case-sensitive. I have the following in my front end and would like to know if I need all of them or if I can reduce the list: This would be easy enough to simply try it out yourself :-) HTTP headers are defined to be case-insensitive. HAProxy emits them fully-lowercased (unless you override this with h1-case-adjust). I recommend to use the lowercased version in the configuration, so just: http-request del-header x-forwarded-for http-request del-header x-forwarded-proto is sufficient. Best regards Tim Düsterhus
Is "http-request del-header" case sensitive?
Running haproxy 2.4.10. Trying to find out if "http-request del-header" is case-sensitive. I have the following in my front end and would like to know if I need all of them or if I can reduce the list: http-request del-header x-forwarded-for http-request del-header x-forwarded-proto http-request del-header X-Forwarded-For http-request del-header X-Forwarded-Proto The goal of that is to ensure that any existing "x-forwarded" header is removed and only the ones inserted by haproxy will be present when the request hits the back end server. The documentation says it is an exact match, but I do not know if that means it's case sensitive. Usually if something says "exact" it WILL be case sensitive. I think I probably want to go with this regex match instead of the four lines above: http-request del-header [Xx]-[Ff]orwarded.+ -m reg Any thoughts or recommendations from those who actually know how the code works? Thanks, Shawn
[PATCH] MINOR haproxy switching to sched_setaffinity on FreeBSD 14
Hi here a little patch proposal. Kind regards. Thanks. 0001-MINOR-haproxy-switching-to-sched_setaffinity-for-Fre.patch Description: Binary data
[PATCH] BUG/MEDIUM: server: avoid changing healthcheck ctx with set server ssl
While giving a fresh try to `set server ssl` (which I wrote), I realised
the behavior is a bit inconsistent. Indeed when using this command over
a server with ssl enabled for the data path but also for the health
check path we have:
- data and health check done using tls
- emit `set server be_foo/srv0 ssl off`
- data path and health check path becomes plain text
- emit `set server be_foo/srv0 ssl on`
- data path becomes tls and health check path remains plain text
while I thought the end result would be:
- data path and health check path comes back in tls
In the current code we indeed erase all connections while deactivating,
but restore only the data path while activating. I made this mistake in
the past because I was testing with a case where the health check plain
text by default.
There are several ways to solve this issue. The cleanest one would
probably be to avoid changing the health check connection when we use
`set server ssl` command, and create a new command `set server
ssl-check` to change this. For now I assumed this would be ok to simply
avoid changing the health check path and be more consistent.
This patch tries to address that and also update the documentation. It
should not break the existing usage with health check on plain text, as
in this case they should have `no-check-ssl` in defaults. Without this
patch, it makes the command unusable in an env where you have a list of
server to add along the way with initial `server-template`, and all
using tls for data and healthcheck path.
For 2.6 we should probably reconsider and add `set server ssl-check`
command for better granularity of cases.
If this solution is accepted, this patch should be backported up to >=
2.4.
The alternative solution was to restore the previous state, but I
believe this will create even more confusion in the future:
--- a/src/server.c
+++ b/src/server.c
@@ -2113,8 +2113,11 @@ void srv_set_ssl(struct server *s, int use_ssl)
return;
s->use_ssl = use_ssl;
- if (s->use_ssl)
+ if (use_ssl) {
s->xprt = xprt_get(XPRT_SSL);
+ if (s->check.use_ssl)
+ s->check.xprt = s->agent.xprt = xprt_get(XPRT_SSL);
+ }
else
s->xprt = s->check.xprt = s->agent.xprt = xprt_get(XPRT_RAW);
}
Signed-off-by: William Dauchy
---
doc/management.txt | 2 ++
src/server.c | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/doc/management.txt b/doc/management.txt
index 147e059f6..b96cbc878 100644
--- a/doc/management.txt
+++ b/doc/management.txt
@@ -2187,6 +2187,8 @@ set server / fqdn
set server / ssl [ on | off ]
This option configures SSL ciphering on outgoing connections to the server.
+ When switch off, all traffic becomes plain text; health check path is not
+ changed.
set severity-output [ none | number | string ]
Change the severity output format of the stats socket connected to for the
diff --git a/src/server.c b/src/server.c
index 2061153bc..d165f50b9 100644
--- a/src/server.c
+++ b/src/server.c
@@ -2116,7 +2116,7 @@ void srv_set_ssl(struct server *s, int use_ssl)
if (s->use_ssl)
s->xprt = xprt_get(XPRT_SSL);
else
- s->xprt = s->check.xprt = s->agent.xprt = xprt_get(XPRT_RAW);
+ s->xprt = xprt_get(XPRT_RAW);
}
#endif /* USE_OPENSSL */
--
2.34.1
Re: [PATCH] MINOR: proxy: add option idle-close-on-response
On Wed, Jan 05, 2022 at 10:53:24PM +0100, William Dauchy wrote: > Avoid closing idle connections if a soft stop is in progress. > > By default, idle connections will be closed during a soft stop. In some > environments, a client talking to the proxy may have prepared some idle > connections in order to send requests later. If there is no proper retry > on write errors, this can result in errors while haproxy is reloading. > Even though a proper implementation should retry on connection/write > errors, this option was introduced to support back compat with haproxy < > v2.4. Indeed before v2.4, we were waiting for a last request to be able > to add a "connection: close" header and advice the client to close the > connection. (...) Perfect, thank you William! I've just added a small paragraph to the doc mentioning the impact of using this for those with long idle connections, and pointers to the relevant options timeout client, timeout http-request and hard-stop-after. I could also have added timeout http-keep-alive by the way. Regardless all of them are cross-references, that should be enough. Now merged, thank you! Willy
