Re: Odd warnings when using "option forwarded"

> That's interesting, because I already had `option forwardfor except > 127.0.0.1` in the frontend which works perfectly. Should that be in the > backend too? No, it's OK to use forwardfor in frontend sections since it is historical behavior. But forwarded doesn't allow that and requires

Re: Odd warnings when using "option forwarded"

Hi Shawn On 26/04/2024 18:34, Shawn Heisey wrote: > I was just reading about the new "option forwarded" capability in 2.9, > so I added it to my config and now I get warnings when checking the config. > > [WARNING]  (253408) : config : parsing [/etc/haproxy/haproxy.cfg:45] : > 'option forwarded'

Re: [PATCH] DOC: configuration.txt: add log-balance documentation

> Got it, sorry for the noise then. No worries, thank you for noticing it! Regards, Aurelien

Re: [PATCH] DOC: configuration.txt: add log-balance documentation

Hi Marko, Thanks for the heads up, In fact "log-balance" directive was removed in > commit b61147fd2a54d4cfc1053a51e87c91cc306bb7ed > Author: Aurelien DARRAGON > Date: Wed Nov 15 11:15:50 2023 +0100 > > MEDIUM: log/balance: merge tcp/http algo with log ones l

Re: [PATCH] MINOR: lua: Add a flag to disable logging to stderr

> On that note, I assume the easiest is to let Willy alter the commit message > to update (or remove) the commit reference when merging? > > Asking just in case you were waiting for me to send an amended patch for it. Yeah I think so, and even if it's not amended, it's not dramatic: the commit

Re: [PATCH] MINOR: lua: Add a flag to disable logging to stderr

> Overall it looks good to me as is. I'll let Aurélien have a quick look > as well in case he sees anything but I'm personally fine with merging > this. Looks good to me as well, nice job Tristan :) Just a side note regarding the comment from the 2nd patch: it's not useful to mention the commit

Re: [PATCH] MINOR: lua: Add a flag to disable logging to stderr

> https://www.arpalert.org/haproxy-api.html (related txn:log() > documentation: > https://www.arpalert.org/src/haproxy-lua-api/2.9/index.html#core.log) Forgot https://www.arpalert.org/src/haproxy-lua-api/2.9/index.html#TXN.log as well (both txn:log(), core:log() and friends with explicit log

Re: [PATCH] MINOR: lua: Add a flag to disable logging to stderr

Hi Tristan, Thanks for the nice work :) Just my 2 cents, in the second patch, since you change the default behavior, you forgot to update your comment from the 1st patch in Lua's doc according to the new behavior: > diff --git a/doc/lua.txt b/doc/lua.txt > index 8d5561668..8d244ab3a 100644 >

Re: [PATCH] MINOR: lua: Add a flag to disable logging to stderr

Hi Guys, I also have a suggestion, while at it: SEND_ERR() which is used to report unexpected Lua errors (because of improper API usage, or due to external factors such as IO/memory issues) currently does a stderr duplication as in hlua_sendlog() I'm thinking that it could be useful to make

Re: sc-set-gpt with expression: internal error, unexpected rule->from=0, please report this bug!

t-gpt0 to set value from an expression"). We have the same issue for the sc-add-gpc action which was greatly inspired from set-gpt, where the switch cases defined in parse_add_gpc() and action_add_gpc() from stick_table.c don't allow tcp-request connection as origin. Please find the attache

Re: [PATCH] REGTESTS: Do not use REQUIRE_VERSION for HAProxy 2.5+ (3)

On 07/08/2023 15:46, Tim Duesterhus wrote: > Introduced in: > > 424981cde REGTEST: add ifnone-forwardfor test > b015b3eb1 REGTEST: add RFC7239 forwarded header tests > > see also: > > fbbbc33df REGTESTS: Do not use REQUIRE_VERSION for HAProxy 2.5+ > --- >

Re: haproxy -dKcnv output

> What I would find clear: > > bool => iif(str,str) => str You're right Tim But in the long term it could be great to share a common output format with the doc as well (to find all relevant info from -dKcnv in the doc, and vice versa) While > bool => iif(str,str) => str and > bool |

Re: haproxy -dKcnv output

Pardon the few typos in the previous mail > $> haproxy -f test.conf -dKcnv | grep iif > iif(string,string): str => bool Replace iff with iif :) Regards, Aurelien

haproxy -dKcnv output

Dear haproxy users, We recently noticed an inconsistency with haproxy -dKcnv output (which may be used to dump all available sample converters from the cli). Here is how a converter is currently being represented in -dKcnv output: conv_name([arg1 ...]) : output_type => input_type For

Re: maint, drain: the right approach

Hi Matteo, > Once the activity on the underlying service has been completed and they > are starting up, I switch back from MAINT to READY (without waiting the > service to be really up). > The haproxy backend got immediately back in the roundrobin pool, even if > the L4 and L7 checks are still

Re: HAProxy 2.7.7: Unexpected messages during shutdown after upgrade

Hi Dominik, > The spikes seem to be fixed now Thanks for the update! However, we are now observing log messages during shutdown that weren’t there before: > > > > May 12, 2023 @ 11:56:24.000 Proxy health_check_http_tcp-scheduler > stopped (cumulated conns: FE: 0, BE: 0). > > May 12,

Re: AW: acl using fc_dst_port not working

n't work in my context, because my logs > show that it contains a different port (not the one I need) Oh ok :/ > But I can wait for a release with the bug fixed, it's not urgent. Thank you for you patience :) Aurelien From 69aaeeb8a54e60ddd66481f91354f0d99c75ec05 Mon Sep 17 00:00:00 2001 From:

Re: acl using fc_dst_port not working

Hi, > During my tests I can see in the logs that fc_dst_port is 8080. However, > the ACL isn't set to true. If I try the same with "acl test > fc_dst 127.0.0.2" it works as expected. However, this is not what I > need. I also tried different matchers like "acl test fc_dst_port -m int > 8080",

Re: stick-table replication not working anymore after Version-Upgrade

> Yes, your assumption is correct. I've now added "localpeer" global > option to the config to make this more robust/more independent from the OS. Glad to know you were able to work around it. Thanks for confirming Regards, Aurelien

Re: stick-table replication not working anymore after Version-Upgrade

> In the HAProxy configuration i'm using the FQDN name, and it seems > HAProxy is just using the short hostname. This seems to be true indeed, "localpeer" default value is retrieved thanks to gethostname() in haproxy However, since no obvious changes around "localpeer" handling occurred between

Re: MQTT mqtt_field_value for CONNACK messages

Hi, > log-format "%{+Q}[var(txn.pv)]" Could you please try adding %B to your log-format string as well? example: > log-format "%{+Q}[var(txn.pv)] (%B)" What I suspect is that the logline is builded before the tcp-response rules are actually evaluated. Some haproxy log format

Re: question for issue

Hi Massimiliano, > i see , > > https://www.haproxy.org/download/2.0/src/ > > > > but there is not the rpm version for doing > > a yum localinstall ? > > > thanx a lot Using http://haproxy.org/download you will only get access to haproxy source code

Re: Issues with dynamic inserted servers

> In fact at some point I had a backend with 5 srv from config + 3 > dynamically inserted. Those new ones got about 50 requests pushed to > them, until they reaches the slowstart delay(I think, must investigate > more), when they stopped being selected for new connection. The status > was L7OK for

Re: Issues with dynamic inserted servers

Hi, I don't know if it could help, but based on Thomas instructions/example, I'm able to reproduce: As weird as it may seem, the 'maxconn' parameter used with dynamic server seems to trigger the issue. Below is a minimal reproducer: > global > stats socket /tmp/ha.sock mode 660 level admin

Re: Haproxy (2.2.26) Wont Start - cannot find default_backend

Hi, > I am having trouble with Haproxy using a configuration was previously > worked and am getting a very odd to me error > > > > Jan 11 13:58:00 ca04vlhaproxy01 haproxy[16077]: [ALERT] 010/135800 > (16077) : Proxy 'graylog_back': unable to find required default_backend: > '#002'. You might

Re: Blocking IO in "lua tasks"

I really appreciate the response. This confirms, that "everything in runtime mode" uses the same thread pool as HTTP workers. This also says that the onlytime we can use "blocking IO" is in "initialization mode", ie, at HAproxy startup/reloads. Happy to help! Considering what we've already

Re: Blocking IO in "lua tasks"

Hi, it feels like that shouldn't be true for "background tasks" as it is mentioned that they run in separate threads That's not 100% true. Lua tasks do run concurrently with the rest of HAProxy processing. But they don't run in separate "threads": they run in separate haproxy tasks. What