Re: [PATCH] MEDIUM: sample: Modify fetchers for req.hdrs and res.hdrs to selectively include / exclude headers
Hi Ruei-Bang, On Fri, Nov 10, 2023 at 01:33:01AM +, Ruei-Bang Chen wrote: > Hi team, > > Based on the feedback from > https://www.mail-archive.com/haproxy@formilux.org/msg44153.html, I have > attached a patch for modifying fetchers for req.hdrs and res.hdrs to > selectively include / exclude headers. Great! > I have the following 3 questions while I was doing this change: > > 1. Should I place the helper function skip_hdr_for_fetch within > http_fetch.c or there is a better place for this? I think it's fine like this. > 2. Should I do this to smp_fetch_hdrs_bin as well? I can update the code, > comments, documentation if that is needed. Indeed, that would be an excellent idea, in order to maintain consistency between the two. > 3.> Not sure if this is the best style for modifying the fetch to support > 10 arguments as it does not align with other fetchers due to the huge > number of characters required. I had a look at it, and it's fine to me. What I'm suspecting is that if users find it useful, it will not be long before some ask for a way to designate prefixes (e.g. select x-companyname-*, or exclude accept-* etc). The way you did it will make it easy to extend it for this, for example, by appending '*' to a header name, so that's fine. Hmmm well, '*' is actually permitted in header field names, so maybe another solution could be that we consider that we'd use prefixes by default and terminante names with ':' to designate full names. E.g. req.hdrs(accept:) would match only "accept" while req.hdrs(accept) would also match accept-encoding, accept-range etc. It's just up to us to decide (and you first since you're the first one to need this, so the ability to extend this and/or to factor arguments may be relevant to your use case. If you want to slightly optimize the loop in smp_fetch_hdrs(), you should call skip_hdr_for_fetch() only when you have at least one argument, so that by default when called with no argument, it skips it. I don't know what the most common use case will be, to be honest, so just take this as a hint, maybe we don't care that much about all headers given that the overall processing around it will be expensive anyway. > Please let me know what are your thoughts on this. I think it's quite nice like this and you patch looks clean. Please just consider the points above in case that gives you some ideas. Similarly I'm seeing that having the '!' in the first argument does add some special cases everywhere down the inner loop. Maybe just having a new name such as "req.hdrs_exc()" to enumerate exclusion would simplify everything, and possibly make it easier even for APIs which will feed these arguments, so as to remove the special case of the first argument. I don't know, but feel free to explore such possibilities, it's important to think about how configs will be used and updated. Very often the amount of work needed to make the core easy to use is less than the work needed externally to adapt to it ;-) Maybe other participants here have any idea on this matter ? Thanks! Willy
[PATCH] MEDIUM: sample: Modify fetchers for req.hdrs and res.hdrs to selectively include / exclude headers
Hi team, Based on the feedback from https://www.mail-archive.com/haproxy@formilux.org/msg44153.html, I have attached a patch for modifying fetchers for req.hdrs and res.hdrs to selectively include / exclude headers. I have the following 3 questions while I was doing this change: 1. Should I place the helper function skip_hdr_for_fetch within http_fetch.c or there is a better place for this? 2. Should I do this to smp_fetch_hdrs_bin as well? I can update the code, comments, documentation if that is needed. 3. Not sure if this is the best style for modifying the fetch to support 10 arguments as it does not align with other fetchers due to the huge number of characters required. Please let me know what are your thoughts on this. Thanks, Ruei-Bang 0001-MEDIUM-sample-Modify-fetchers-for-req.hdrs-and-res.h.patch Description: 0001-MEDIUM-sample-Modify-fetchers-for-req.hdrs-and-res.h.patch
Should we change the -c output?
Hello,
haproxy -c seems to be too verbose in the systemd logs by
showing "Configuration file is valid" for every reloads.
Is there anyone against removing this message by default?
This will still output the alerts and warnings if some exists but the
"Configuration file is valid" message will only be displayed in
combination with -V.
People tend to use the return code of the command and not the output,
but I prefer to ask.
Change will only be applied starting from 2.9. Patch attached.
--
William Lallemand
>From d189f5473f0ed0594c693646d424d0a9e03eabaf Mon Sep 17 00:00:00 2001
From: William Lallemand
Date: Thu, 9 Nov 2023 14:48:50 +0100
Subject: [PATCH] MEDIUM: startup: MODE_CHECK is quiet by default
MODE_CHECK does not output "Configuration file is valid" by default
anymore. To display this message the -V option must be used with -c.
However the warning and errors are still output by default if they
exist.
This allows to clean the output of the systemd unit file with is doing a
-c.
---
src/haproxy.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/haproxy.c b/src/haproxy.c
index 7a4f49fa6..d728f0c21 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -2374,7 +2374,8 @@ static void init(int argc, char **argv)
if (pr || px) {
/* At least one peer or one listener has been found */
- qfprintf(stdout, "Configuration file is valid\n");
+ if (global.mode & MODE_VERBOSE)
+qfprintf(stdout, "Configuration file is valid\n");
deinit_and_exit(0);
}
qfprintf(stdout, "Configuration file has no error but will not start (no listener) => exit(2).\n");
--
2.39.2
??external-check?? does not work properly in Rocklinux8
hi, 1??docker pull haproxy:2.8.3 2??haproxy.conf??external-check command /var/lib/haproxy/test.sh When the container is running in the RockLinux environment, the test.sh script is not called for execution. On the contrary, the Centos environment can be called and executed normally. Is there a configuration issue? Or a bug? Seeking a solution, thank you very much??
Re: unsupported protocol family 2 for address 'quic4@0.0.0.0:4
> Am 08.11.2023 um 21:29 schrieb Shawn Heisey : > > On 11/8/23 10:11, Christoph Kukulies wrote: >> frontend web80 >> bind 0.0.0.0:80 name web80 >> default_backend be-local-81 > > Normally you definitely would not want this in your production config... > typically any request coming in on port 80 should be redirected to https > without ever being sent to a backend webserver. > Hi Shawn, thanks. I was aware of this, of course. Just wanted to use it to verify the bind quic4 syntax, my haproxy was failing upon, for now known reasons (wrong binary on my side). But thanks again for explaining and supporting. -- Christoph > That config is only useful as-is for my CI pipeline. I have updated it so > it's much more in line with how my production setup is configured. This is > how I configure port 80: > > frontend web80 >description Redirect to https >bind 0.0.0.0:80 name web80 >redirect scheme https >default_backend be_deny > > backend be_deny >description Back end with no servers that denies all requests. >no log >log 127.0.0.1 len 65535 format rfc5424 local0 notice err >http-request deny > > Thanks, > Shawn > > smime.p7s Description: S/MIME cryptographic signature
