Re: Question about substring match (*_sub)
the following usually works for performance profiling. 1) setup work stand (similar to what you use in production) 2) use valgrind + callgrind for collecting traces 3) put workload 4) aggregate using kcachegrind most probably you were going to do very similar things already :) сб, 23 янв. 2021 г. в 03:18, Aleksandar Lazic : > Hi. > > I would like to take a look into the substring match implementation > because of > the comment there. > > > http://git.haproxy.org/?p=haproxy.git;a=blob;f=src/pattern.c;h=8729769e5e549bcd4043ae9220ceea440445332a;hb=HEAD#l767 > > "NB: Suboptimal, should be rewritten using a Boyer-Moore method." > > Now before I take a deeper look into the different algorithms about > sub-string > match I would like to know which pattern and length is a "common" use case > for the user here? > > There are so many different algorithms which are mostly implemented in the > Smart Tool ( https://github.com/smart-tool/smart ) therefore it would be > interesting to know some metrics about the use cases. > > Thanks for sharing. > Best regards > > Aleks > >
Question about substring match (*_sub)
Hi. I would like to take a look into the substring match implementation because of the comment there. http://git.haproxy.org/?p=haproxy.git;a=blob;f=src/pattern.c;h=8729769e5e549bcd4043ae9220ceea440445332a;hb=HEAD#l767 "NB: Suboptimal, should be rewritten using a Boyer-Moore method." Now before I take a deeper look into the different algorithms about sub-string match I would like to know which pattern and length is a "common" use case for the user here? There are so many different algorithms which are mostly implemented in the Smart Tool ( https://github.com/smart-tool/smart ) therefore it would be interesting to know some metrics about the use cases. Thanks for sharing. Best regards Aleks
Re: Proxy protocol unique id and idle connection
Tim Düsterhus wrote: > Amaury, > Am 21.01.21 um 16:40 schrieb (Amaury Denoyelle): > > I have a question for you on the case of the proxy protocol. One of > > these special parameters to identify a connection is the content of the > > proxy protocol block. However, this breaks the following reg-tests : > > - proxy_protocol_send_unique_id.vtc (from commit > > cf6e0c8a836da211946fa637020e776286093633) > > What happens in the reg-test with my modification is that on the second > > client request, a new proxy protocol packet for connection comparison is > > generated with the header of the second request as unique id. It is > > identified that the previous connection cannot be reused (different > > unique id in proxy protocol), and thus a new connection is established. > > However, on the reg-tests, it is expected that the first connection is > > reused and thus no proxy protocol resend. > > What is your opinion on this ? On my side, I think the behavior of my > > implementation is less surprising, but if it is a real use-case, I do > > not want to break it without knowing it. > Sending unique IDs via PROXY v2 was implemented for TCP proxying. The > documentation already states that: > It can > lead to unexpected results in "mode http", because the > generated unique ID is also used for the first HTTP request > within a Keep-Alive connection. > So: > 1. No one should send unique IDs via PROXY v2 for HTTP traffic. There's > headers for that. > 2. It didn't make sense to actually prevent users from doing that. > 3. Preventing sharing for such connections does not actually *break* > anything, instead it just reduces performance. > 4. With the reduced performance we are back to (1): You really shouldn't > do this. > 5. The test was just to make sure it behaves somewhat sanely (i.e. does > not send entirely wrong information) for HTTP traffic. My intention was > not to test that Keep-Alive is possible. > So: Please go ahead with your modification, change the test to make sure > keep-alive does not happen and adjust the documentation as necessary. Hi Tim, Thanks for your quick answer. I will continue my work and adjust the test and the doc. -- Amaury Denoyelle
Re: HTTP/2 streams - how they're balanced?
Hi Maksim, On Thu, Jan 21, 2021 at 09:27:33PM +0300, ?? ? wrote: > Hi! > > Can anyone please explain or point out in the documentation how streams in > HTTP/2 connection are balanced? Like any other HTTP stream. There's no relation between H2 streams. There was already no relation between H1 streams, but it was possible to know that one of them was the first one. For H2 there's no first one at all since they're all parallel. > Right now I have haproxy=2.1.4 with http/2 balancer configured and it seems > to me that gRPC-requests over a single connection from a client are always > forwarded to the same backend server. > > Am I right or not? Are there any configuration options for this? Not only there is no reason for this, but if you asked me how to achieve this I wouldn't know how to do it :-) The load balancing happens for each request, following the configured LB algorithm. > Forget to add my config. It looks like this one (http/2 end to end, no ssl, > random balanced): > > frontend grpc.service:8080 > bind ipv6@xxx:8080 proto h2 > > mode http > option http-use-htx > timeout client 30s > > default_backend be1:grpc.service:8080 > > backend be1:grpc.service:8080 > mode http > balance random > > retries 1 > timeout connect 25 > timeout server 30s > timeout queue 1s > > # Set other options > option http-use-htx > option redispatch > > default-server weight 50 > > server server1:17355 xxx:17355 proto h2 > server server2:17355 yyy:17355 proto h2 > server server3:17355 zzz:17355 proto h2 I see nothing wrong in this config, for me it's OK. However, is there any reason for you to run on a version that's affected by 221 known bugs ? Maybe what you're observing is just the consequence of one of these ? https://www.haproxy.org/bugs/bugs-2.1.4.html Please update it and retry, just in case. Cheers, Willy
Re: HTTP/2 streams - how they're balanced?
Thank you, Willy! I will take a try with a new version if it could help :) пт, 22 янв. 2021 г. в 11:43, Willy Tarreau : > Hi Maksim, > > On Thu, Jan 21, 2021 at 09:27:33PM +0300, ?? ? wrote: > > Hi! > > > > Can anyone please explain or point out in the documentation how streams > in > > HTTP/2 connection are balanced? > > Like any other HTTP stream. There's no relation between H2 streams. There > was already no relation between H1 streams, but it was possible to know > that one of them was the first one. For H2 there's no first one at all > since they're all parallel. > > > Right now I have haproxy=2.1.4 with http/2 balancer configured and it > seems > > to me that gRPC-requests over a single connection from a client are > always > > forwarded to the same backend server. > > > > Am I right or not? Are there any configuration options for this? > > Not only there is no reason for this, but if you asked me how to achieve > this I wouldn't know how to do it :-) > > The load balancing happens for each request, following the configured LB > algorithm. > > > Forget to add my config. It looks like this one (http/2 end to end, no > ssl, > > random balanced): > > > > frontend grpc.service:8080 > > bind ipv6@xxx:8080 proto h2 > > > > mode http > > option http-use-htx > > timeout client 30s > > > > default_backend be1:grpc.service:8080 > > > > backend be1:grpc.service:8080 > > mode http > > balance random > > > > retries 1 > > timeout connect 25 > > timeout server 30s > > timeout queue 1s > > > > # Set other options > > option http-use-htx > > option redispatch > > > > default-server weight 50 > > > > server server1:17355 xxx:17355 proto h2 > > server server2:17355 yyy:17355 proto h2 > > server server3:17355 zzz:17355 proto h2 > > I see nothing wrong in this config, for me it's OK. However, is there > any reason for you to run on a version that's affected by 221 known > bugs ? Maybe what you're observing is just the consequence of one of > these ? > > https://www.haproxy.org/bugs/bugs-2.1.4.html > > Please update it and retry, just in case. > > Cheers, > Willy >
Re: [PATCH 1/1] BUG/MINOR: lua: define _GNU_SOURCE for LLONG_MAX
On Thu, Jan 21, 2021 at 09:14:07PM +, Bertrand Jacquin wrote: > Lua requires LLONG_MAX defined with __USE_ISOC99 which is set by > _GNU_SOURCE, not necessarely defined by default on old compiler/glibc. (...) Applied, thanks! Willy
Re: [PATCH 1/1] MINOR: lua: remove unused variable
On Thu, Jan 21, 2021 at 07:14:46PM +, Bertrand Jacquin wrote: > hlua_init() uses 'idx' only in openssl related code, while 'i' is used > in shared code and is safe to be reused. This commit replaces the use of > 'idx' with 'i' (...) Ah you're right, I also met this one one. Now applied, thanks Bertrand! Willy
Re: [PATCH] improve ssl guarding by switching to macro SSL_CLIENT_HELLO_CB instead of openssl version
ping
вт, 19 янв. 2021 г. в 23:24, Илья Шипицин :
> Any update on this?
>
> On Mon, Jan 18, 2021, 3:56 PM Илья Шипицин wrote:
>
>> we can do nasty thing.
>> SSL_CLIENT_HELLO_CB is not defined for BoringSSL, we can (in
>> openssl-compat.h) check whether BoringSSL is used and define that macro.
>>
>> I'm not sure it is good thing.
>>
>> if you thing it is, please modify patch when applying. I'm ok with such
>> change.
>>
>> пн, 18 янв. 2021 г. в 15:53, Илья Шипицин :
>>
>>>
>>>
>>> пн, 18 янв. 2021 г. в 15:09, William Lallemand :
>>>
Hello,
On Sat, Jan 16, 2021 at 11:25:05PM +0500, Илья Шипицин wrote:
> Hello,
>
> next openssl guarding patch
>
> Ilya
> From b5ff0a9f1e0d2edc84981b39050e7f21d2b08ba8 Mon Sep 17 00:00:00 2001
> From: Ilya Shipitsin
> Date: Sat, 16 Jan 2021 23:15:12 +0500
> Subject: [PATCH] BUILD: ssl: guard Client Hello callbacks with
> SSL_CLIENT_HELLO_CB macro instead of openssl version
>
> ---
> include/haproxy/ssl_sock.h | 2 +-
> src/ssl_sock.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/haproxy/ssl_sock.h b/include/haproxy/ssl_sock.h
> index ebfdb19ab..bde75b632 100644
> --- a/include/haproxy/ssl_sock.h
> +++ b/include/haproxy/ssl_sock.h
> @@ -92,7 +92,7 @@ int ssl_sock_load_global_dh_param_from_file(const
char *filename);
> void ssl_free_dh(void);
> #endif
> void ssl_free_engines(void);
> -#if ((HA_OPENSSL_VERSION_NUMBER >= 0x10101000L) ||
defined(OPENSSL_IS_BORINGSSL))
> +#if (defined(SSL_CLIENT_HELLO_CB) || defined(OPENSSL_IS_BORINGSSL))
> int ssl_sock_switchctx_err_cbk(SSL *ssl, int *al, void *priv);
> #ifdef OPENSSL_IS_BORINGSSL
> int ssl_sock_switchctx_cbk(const struct ssl_early_callback_ctx *ctx);
> diff --git a/src/ssl_sock.c b/src/ssl_sock.c
> index 5ac81d36a..3e133d423 100644
> --- a/src/ssl_sock.c
> +++ b/src/ssl_sock.c
> @@ -2290,7 +2290,7 @@ static void ssl_sock_switchctx_set(SSL *ssl,
SSL_CTX *ctx)
> SSL_set_SSL_CTX(ssl, ctx);
> }
>
> -#if ((HA_OPENSSL_VERSION_NUMBER >= 0x10101000L) ||
defined(OPENSSL_IS_BORINGSSL))
> +#if (defined(SSL_CLIENT_HELLO_CB) || defined(OPENSSL_IS_BORINGSSL))
>
> int ssl_sock_switchctx_err_cbk(SSL *ssl, int *al, void *priv)
> {
We probably want to remove the defined(IS_BORINGSSL) from the
ssl_sock.c too.
Why don't you define a macro constant with the feature name in
openssl-compat.h and test this constant in ssl_sock.c? Like it was done
for various fonctions.
>>>
>>> it depends. I'd consider removing OPENSSL_IS_BORINGSSL as a future
>>> improvements.
>>>
>>> this particular guard is used 2 times only (in *.h and *.c files),
>>> readability is good.
>>>
>>>
>>>
Regards,
--
William Lallemand
>>>
Re: [PATCH] improve ssl guarding by switching to macro SSL_CLIENT_HELLO_CB instead of openssl version
You could define a HAVE_SSL_* macro like it's done elsewhere in the
code, for example "HAVE_SSL_CLIENT_HELLO_CB".
On Fri, Jan 22, 2021 at 06:59:58PM +0500, Илья Шипицин wrote:
> ping
>
> вт, 19 янв. 2021 г. в 23:24, Илья Шипицин :
>
> > Any update on this?
> >
> > On Mon, Jan 18, 2021, 3:56 PM Илья Шипицин wrote:
> >
> >> we can do nasty thing.
> >> SSL_CLIENT_HELLO_CB is not defined for BoringSSL, we can (in
> >> openssl-compat.h) check whether BoringSSL is used and define that macro.
> >>
> >> I'm not sure it is good thing.
> >>
> >> if you thing it is, please modify patch when applying. I'm ok with such
> >> change.
> >>
> >> пн, 18 янв. 2021 г. в 15:53, Илья Шипицин :
> >>
> >>>
> >>>
> >>> пн, 18 янв. 2021 г. в 15:09, William Lallemand :
> >>>
> Hello,
>
> On Sat, Jan 16, 2021 at 11:25:05PM +0500, Илья Шипицин wrote:
> > Hello,
> >
> > next openssl guarding patch
> >
> > Ilya
>
> > From b5ff0a9f1e0d2edc84981b39050e7f21d2b08ba8 Mon Sep 17 00:00:00 2001
> > From: Ilya Shipitsin
> > Date: Sat, 16 Jan 2021 23:15:12 +0500
> > Subject: [PATCH] BUILD: ssl: guard Client Hello callbacks with
> > SSL_CLIENT_HELLO_CB macro instead of openssl version
> >
> > ---
> > include/haproxy/ssl_sock.h | 2 +-
> > src/ssl_sock.c | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/haproxy/ssl_sock.h b/include/haproxy/ssl_sock.h
> > index ebfdb19ab..bde75b632 100644
> > --- a/include/haproxy/ssl_sock.h
> > +++ b/include/haproxy/ssl_sock.h
> > @@ -92,7 +92,7 @@ int ssl_sock_load_global_dh_param_from_file(const
> char *filename);
> > void ssl_free_dh(void);
> > #endif
> > void ssl_free_engines(void);
> > -#if ((HA_OPENSSL_VERSION_NUMBER >= 0x10101000L) ||
> defined(OPENSSL_IS_BORINGSSL))
> > +#if (defined(SSL_CLIENT_HELLO_CB) || defined(OPENSSL_IS_BORINGSSL))
> > int ssl_sock_switchctx_err_cbk(SSL *ssl, int *al, void *priv);
> > #ifdef OPENSSL_IS_BORINGSSL
> > int ssl_sock_switchctx_cbk(const struct ssl_early_callback_ctx *ctx);
> > diff --git a/src/ssl_sock.c b/src/ssl_sock.c
> > index 5ac81d36a..3e133d423 100644
> > --- a/src/ssl_sock.c
> > +++ b/src/ssl_sock.c
> > @@ -2290,7 +2290,7 @@ static void ssl_sock_switchctx_set(SSL *ssl,
> SSL_CTX *ctx)
> > SSL_set_SSL_CTX(ssl, ctx);
> > }
> >
> > -#if ((HA_OPENSSL_VERSION_NUMBER >= 0x10101000L) ||
> defined(OPENSSL_IS_BORINGSSL))
> > +#if (defined(SSL_CLIENT_HELLO_CB) || defined(OPENSSL_IS_BORINGSSL))
> >
> > int ssl_sock_switchctx_err_cbk(SSL *ssl, int *al, void *priv)
> > {
>
> We probably want to remove the defined(IS_BORINGSSL) from the
> ssl_sock.c too.
> Why don't you define a macro constant with the feature name in
> openssl-compat.h and test this constant in ssl_sock.c? Like it was done
> for various fonctions.
>
> >>>
> >>> it depends. I'd consider removing OPENSSL_IS_BORINGSSL as a future
> >>> improvements.
> >>>
> >>> this particular guard is used 2 times only (in *.h and *.c files),
> >>> readability is good.
> >>>
> >>>
> >>>
>
> Regards,
>
> --
> William Lallemand
>
> >>>
--
William Lallemand
[ANNOUNCE] haproxy-2.4-dev6
Hi, HAProxy 2.4-dev6 was released on 2021/01/22. It added 88 new commits after version 2.4-dev5. These last two weeks have been pretty annoying with a number of regressions popping up into 2.4-dev and slipping into older versions. Most of them are not serious but still, they did affect some people and required to go back to the white board to design better (or incremental) fixes. What's annoying when this situation happens is that it's a spiral loop and it's hard to get away from it: users start to rightfully complain, each problem is urgent and this leaves less time to produce good and durable fixes, so chances are that bugs will pop up again. Given the time spent doing nothing but chasing issues, and the fact that patches are starting to flow from a growing number of contributors (which is great), I'm thinking about extending the feature freeze point to somewhere between mid and end of February. But please be gentle: patch reviews consume a lot of time and prevent progress from being made on features that are initially expected before the freeze point. As I've said, I want the time after that point to be used for tests, bug fixes, cleanups and documentation. This means that if your patches are essentially cleanups with no real impact on the code paths, it's better to send them a bit later so that the dangerous stuff can be completed and doesn't get merged too late. This is particularly true for the HTX+tunnel rework that Christopher is still trying hard to finish and that's been blocking the merging of WebSocket/H2 for about a month now. As a special case, I'll continue to take QUIC development patches after the freeze point as long as they can't break existing code, since it's not used yet and will be marked experimental once released. Thus to whoever still has important stuff to get merged for 2.4, please understand that you still have more than a week but less than a month, and that it may require some prioritizing in your work if you want the important stuff to get there, otherwise it will be for 2.5. And with the current situation everywhere in the world, be realistic, time flies very fast, lucky are those who manage to get some work done by the end of the day. This version addresses a few issues that popped up recently, including one that managed to crash the process once yesterday on haproxy.org using H2, one causing high CPU usage and CLOSE_WAITs on partial H2 frames, a fix for the checks which can cause a crash, and a better version of the DNS fix that previously caused some regressions. The rest should be mostly harmless or rare enough to encounter. I'm aware of a possible (though unlikely) risk of deadlock on "show peers" that Fred discovered, but it has always been there and people use the command all the time so it's not that critical, so it will likely be for next one. Bugs aside, some progress was made in these areas: - the prometheus exporter is getting some rework from William Dauchy to homogenize the way metrics are handled and try to make them easier to add in the future, and to permit requesting certain metrics only. This is an ongoing work, but it's nice if some prometheus users test the changes from time to time and report any unexpected change early. - debugging: "show fd" will now report even more info, including suspicious entries, and BUG_ON() will emit a backtrace in addition to the faulty condition - the cache was slightly simplified by not storing responses with an unknown content-encoding anymore. - William Dauchy's url_enc() converter was finally merged, it performs URL-encoding for use in the query string. - HTTP 501-no-implemented was added to the known response messages, this will be used to reject certain situations that are not handled and make no sense (e.g. an HTTP upgrade request based on a message with a body). - "server" statements in frontends used to only emit warnings, now they are real errors, as they've been the cause of several reports lately, each time in completely absurd situations resulting from copy-paste mistakes, but where the user got confused by the consequences. - more traces in the peers - more regtests. That's about all. With a bit of luck we can merge Christopher's HTX updates and Amaury's Websocket work and idle connection rework next week. This would already be quite a relief given the sensitivity of those areas! I think we'll issue another round of 2.3 and 2.2 later next week to flush the pipe of pending fixes. In the mean time, let's just play with it and report any breakage. Please find the usual URLs below : Site index : http://www.haproxy.org/ Discourse: http://discourse.haproxy.org/ Slack channel: https://slack.haproxy.org/ Issue tracker: https://github.com/haproxy/haproxy/issues Wiki : https://github.com/haproxy/wiki/wiki Sources : http://www.haproxy.org/download/2.4/src/ Git repository
Re: Great content ideas for your blog
Hello Haproxy Editorial Team, I hope you are doing well. I believe you might have a busy schedule, just checking in to see if you received my last email about the guest post collaboration. I'd really like to hear what you think. Regards, Stella -Original Message- Hello Haproxy Editorial Team, Did you receive our last email? I'd really like to hear what you think. Regards, Stella -Original Message- Haproxy Editorial Team, My name is Stella & I am reaching out from datadome.co. Today I came across your post "Bot Protection with HAProxy"- https://www.haproxy.com/blog/bot-protection-with-haproxy/, I certainly respect the efforts you put into your content. Your content is engaging and informative. Since we each share a comparable interest, may I ask, do you accept a contribution to "haproxy.com"? I've countless thoughts for your website, online site visitors will really like them. Please let me recognize if you would be involved in listening to them. I'd be very blissful to pass by alongside some writing samples & ideas. Looking ahead to your thoughts. Regards, Stella
Re: [PATCH] improve ssl guarding by switching to macro SSL_CLIENT_HELLO_CB instead of openssl version
updated patch attached
пт, 22 янв. 2021 г. в 19:16, William Lallemand :
> You could define a HAVE_SSL_* macro like it's done elsewhere in the
> code, for example "HAVE_SSL_CLIENT_HELLO_CB".
>
>
> On Fri, Jan 22, 2021 at 06:59:58PM +0500, Илья Шипицин wrote:
> > ping
> >
> > вт, 19 янв. 2021 г. в 23:24, Илья Шипицин :
> >
> > > Any update on this?
> > >
> > > On Mon, Jan 18, 2021, 3:56 PM Илья Шипицин
> wrote:
> > >
> > >> we can do nasty thing.
> > >> SSL_CLIENT_HELLO_CB is not defined for BoringSSL, we can (in
> > >> openssl-compat.h) check whether BoringSSL is used and define that
> macro.
> > >>
> > >> I'm not sure it is good thing.
> > >>
> > >> if you thing it is, please modify patch when applying. I'm ok with
> such
> > >> change.
> > >>
> > >> пн, 18 янв. 2021 г. в 15:53, Илья Шипицин :
> > >>
> > >>>
> > >>>
> > >>> пн, 18 янв. 2021 г. в 15:09, William Lallemand <
> wlallem...@haproxy.com>:
> > >>>
> > Hello,
> >
> > On Sat, Jan 16, 2021 at 11:25:05PM +0500, Илья Шипицин wrote:
> > > Hello,
> > >
> > > next openssl guarding patch
> > >
> > > Ilya
> >
> > > From b5ff0a9f1e0d2edc84981b39050e7f21d2b08ba8 Mon Sep 17 00:00:00
> 2001
> > > From: Ilya Shipitsin
> > > Date: Sat, 16 Jan 2021 23:15:12 +0500
> > > Subject: [PATCH] BUILD: ssl: guard Client Hello callbacks with
> > > SSL_CLIENT_HELLO_CB macro instead of openssl version
> > >
> > > ---
> > > include/haproxy/ssl_sock.h | 2 +-
> > > src/ssl_sock.c | 2 +-
> > > 2 files changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/include/haproxy/ssl_sock.h
> b/include/haproxy/ssl_sock.h
> > > index ebfdb19ab..bde75b632 100644
> > > --- a/include/haproxy/ssl_sock.h
> > > +++ b/include/haproxy/ssl_sock.h
> > > @@ -92,7 +92,7 @@ int
> ssl_sock_load_global_dh_param_from_file(const
> > char *filename);
> > > void ssl_free_dh(void);
> > > #endif
> > > void ssl_free_engines(void);
> > > -#if ((HA_OPENSSL_VERSION_NUMBER >= 0x10101000L) ||
> > defined(OPENSSL_IS_BORINGSSL))
> > > +#if (defined(SSL_CLIENT_HELLO_CB) ||
> defined(OPENSSL_IS_BORINGSSL))
> > > int ssl_sock_switchctx_err_cbk(SSL *ssl, int *al, void *priv);
> > > #ifdef OPENSSL_IS_BORINGSSL
> > > int ssl_sock_switchctx_cbk(const struct ssl_early_callback_ctx
> *ctx);
> > > diff --git a/src/ssl_sock.c b/src/ssl_sock.c
> > > index 5ac81d36a..3e133d423 100644
> > > --- a/src/ssl_sock.c
> > > +++ b/src/ssl_sock.c
> > > @@ -2290,7 +2290,7 @@ static void ssl_sock_switchctx_set(SSL *ssl,
> > SSL_CTX *ctx)
> > > SSL_set_SSL_CTX(ssl, ctx);
> > > }
> > >
> > > -#if ((HA_OPENSSL_VERSION_NUMBER >= 0x10101000L) ||
> > defined(OPENSSL_IS_BORINGSSL))
> > > +#if (defined(SSL_CLIENT_HELLO_CB) ||
> defined(OPENSSL_IS_BORINGSSL))
> > >
> > > int ssl_sock_switchctx_err_cbk(SSL *ssl, int *al, void *priv)
> > > {
> >
> > We probably want to remove the defined(IS_BORINGSSL) from the
> > ssl_sock.c too.
> > Why don't you define a macro constant with the feature name in
> > openssl-compat.h and test this constant in ssl_sock.c? Like it was
> done
> > for various fonctions.
> >
> > >>>
> > >>> it depends. I'd consider removing OPENSSL_IS_BORINGSSL as a future
> > >>> improvements.
> > >>>
> > >>> this particular guard is used 2 times only (in *.h and *.c files),
> > >>> readability is good.
> > >>>
> > >>>
> > >>>
> >
> > Regards,
> >
> > --
> > William Lallemand
> >
> > >>>
>
> --
> William Lallemand
>
From c733754941556b30bbc3e4ad4f8f917d5a885282 Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin
Date: Sat, 23 Jan 2021 00:09:14 +0500
Subject: [PATCH] BUILD: ssl: guard Client Hello callbacks with
HAVE_SSL_CLIENT_HELLO_CB macro instead of openssl version
let us introduce new macro HAVE_SSL_CLIENT_HELLO_CB and guard
callback functions with it
---
include/haproxy/openssl-compat.h | 4
include/haproxy/ssl_sock.h | 2 +-
src/ssl_sock.c | 2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/include/haproxy/openssl-compat.h b/include/haproxy/openssl-compat.h
index 3cba3627f..b4af429cf 100644
--- a/include/haproxy/openssl-compat.h
+++ b/include/haproxy/openssl-compat.h
@@ -45,6 +45,10 @@
#define HAVE_SSL_CTX_SET_CIPHERSUITES
#endif
+#if (defined(SSL_CLIENT_HELLO_CB) || defined(OPENSSL_IS_BORINGSSL))
+#define HAVE_SSL_CLIENT_HELLO_CB
+#endif
+
#if ((OPENSSL_VERSION_NUMBER >= 0x1000200fL) && !defined(OPENSSL_NO_TLSEXT) && !defined(LIBRESSL_VERSION_NUMBER) && !defined(OPENSSL_IS_BORINGSSL))
#define HAVE_SL_CTX_ADD_SERVER_CUSTOM_EXT
#endif
diff --git a/include/haproxy/ssl_sock.h b/include/haproxy/ssl_sock.h
index ebfdb19ab..c52d99144 100644
--- a/include/haproxy/ssl_sock.h
+++ b/include/haproxy/ssl_sock.h
@@ -92,7 +92,7 @@ int
Re: [PATCH] improve ssl guarding by switching to macro SSL_CLIENT_HELLO_CB instead of openssl version
On Sat, Jan 23, 2021 at 12:23:01AM +0500, Илья Шипицин wrote: > updated patch attached > Thanks, merged. -- William Lallemand
[PATCH 1/6] MINOR: contrib/prometheus-exporter: better output of Not-a-Number
Not necessarily mandatory but I saw a few prometheus client parsing only
`NaN`. Also most librarries do output `NaN`
Signed-off-by: William Dauchy
---
contrib/prometheus-exporter/service-prometheus.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/prometheus-exporter/service-prometheus.c
b/contrib/prometheus-exporter/service-prometheus.c
index aa72382d9..bc9ebf3fc 100644
--- a/contrib/prometheus-exporter/service-prometheus.c
+++ b/contrib/prometheus-exporter/service-prometheus.c
@@ -415,7 +415,7 @@ static int promex_srv_status(struct server *sv)
/* Convert a field to its string representation and write it in , followed
* by a newline, if there is enough space. non-numeric value are converted in
- * "Nan" because Prometheus only support numerical values (but it is
unexepceted
+ * "NaN" because Prometheus only support numerical values (but it is
unexepceted
* to process this kind of value). It returns 1 on success. Otherwise, it
* returns 0. The buffer's length must not exceed value.
*/
@@ -424,14 +424,14 @@ static int promex_metric_to_str(struct buffer *out,
struct field *f, size_t max)
int ret = 0;
switch (field_format(f, 0)) {
- case FF_EMPTY: ret = chunk_strcat(out, "Nan\n"); break;
+ case FF_EMPTY: ret = chunk_strcat(out, "NaN\n"); break;
case FF_S32: ret = chunk_appendf(out, "%d\n", f->u.s32);
break;
case FF_U32: ret = chunk_appendf(out, "%u\n", f->u.u32);
break;
case FF_S64: ret = chunk_appendf(out, "%lld\n", (long
long)f->u.s64); break;
case FF_U64: ret = chunk_appendf(out, "%llu\n", (unsigned
long long)f->u.u64); break;
case FF_FLT: ret = chunk_appendf(out, "%f\n", f->u.flt);
break;
- case FF_STR: ret = chunk_strcat(out, "Nan\n"); break;
- default: ret = chunk_strcat(out, "Nan\n"); break;
+ case FF_STR: ret = chunk_strcat(out, "NaN\n"); break;
+ default: ret = chunk_strcat(out, "NaN\n"); break;
}
if (!ret || out->data > max)
return 0;
--
2.29.2
[PATCH 4/6] MINOR: contrib/prometheus-exporter: use fill_be_stats for backend dump
use `stats_fill_be_stats` when possible to avoid duplicating code; make
use of field selector to get the needed field only.
the only difference is on `haproxy_backend_downtime_seconds_total` as
stats.c is testing `px->srv`. This behaviour is present since commit
7344f4789321ef8ce2ce17cf73dabd672f7c8c6 ("MINOR: stats: only report
backend's down time if it has servers"). The end result is a NaN instead
of a zero when no server are present.
Signed-off-by: William Dauchy
---
.../prometheus-exporter/service-prometheus.c | 163 ++
1 file changed, 15 insertions(+), 148 deletions(-)
diff --git a/contrib/prometheus-exporter/service-prometheus.c
b/contrib/prometheus-exporter/service-prometheus.c
index bc9ebf3fc..12fe3ee90 100644
--- a/contrib/prometheus-exporter/service-prometheus.c
+++ b/contrib/prometheus-exporter/service-prometheus.c
@@ -685,8 +685,8 @@ static int promex_dump_back_metrics(struct appctx *appctx,
struct htx *htx)
struct channel *chn = si_ic(appctx->owner);
struct ist out = ist2(trash.area, 0);
size_t max = htx_get_max_blksz(htx, channel_htx_recv_max(chn, htx));
+ struct field *stats = stat_l[STATS_DOMAIN_PROXY];
int ret = 1;
- uint32_t weight;
double secs;
for (;appctx->st2 < ST_F_TOTAL_FIELDS; appctx->st2++) {
@@ -700,46 +700,13 @@ static int promex_dump_back_metrics(struct appctx
*appctx, struct htx *htx)
if (px->disabled || px->uuid <= 0 || !(px->cap &
PR_CAP_BE))
goto next_px;
+ if (!stats_fill_be_stats(px, 0, stats,
ST_F_TOTAL_FIELDS, &(appctx->st2)))
+ return -1;
+
switch (appctx->st2) {
case ST_F_STATUS:
val = mkf_u32(FO_STATUS,
(px->lbprm.tot_weight > 0 || !px->srv) ? 1 : 0);
break;
- case ST_F_SCUR:
- val = mkf_u32(0, px->beconn);
- break;
- case ST_F_SMAX:
- val = mkf_u32(FN_MAX,
px->be_counters.conn_max);
- break;
- case ST_F_SLIM:
- val = mkf_u32(FO_CONFIG|FN_LIMIT,
px->fullconn);
- break;
- case ST_F_STOT:
- val = mkf_u64(FN_COUNTER,
px->be_counters.cum_conn);
- break;
- case ST_F_RATE_MAX:
- val = mkf_u32(0,
px->be_counters.sps_max);
- break;
- case ST_F_LASTSESS:
- val = mkf_s32(FN_AGE,
be_lastsession(px));
- break;
- case ST_F_QCUR:
- val = mkf_u32(0, px->nbpend);
- break;
- case ST_F_QMAX:
- val = mkf_u32(FN_MAX,
px->be_counters.nbpend_max);
- break;
- case ST_F_CONNECT:
- val = mkf_u64(FN_COUNTER,
px->be_counters.connect);
- break;
- case ST_F_REUSE:
- val = mkf_u64(FN_COUNTER,
px->be_counters.reuse);
- break;
- case ST_F_BIN:
- val = mkf_u64(FN_COUNTER,
px->be_counters.bytes_in);
- break;
- case ST_F_BOUT:
- val = mkf_u64(FN_COUNTER,
px->be_counters.bytes_out);
- break;
case ST_F_QTIME:
secs =
(double)swrate_avg(px->be_counters.q_time, TIME_STATS_SAMPLES) / 1000.0;
val = mkf_flt(FN_AVG, secs);
@@ -772,139 +739,39 @@ static int promex_dump_back_metrics(struct appctx
*appctx, struct htx *htx)
secs =
(double)px->be_counters.ttime_max / 1000.0;
val = mkf_flt(FN_MAX, secs);
break;
- case ST_F_DREQ:
- val = mkf_u64(FN_COUNTER,
px->be_counters.denied_req);
- break;
- case ST_F_DRESP:
- val =
[PATCH 0/6] backend and server stats reuse
Hi Christopher, This is a new series which follows the work done on frontend side. It starts with two minor patches which are more comestic; then it addresses backend and servers. I made sure to not reproduce the same mistake for the default case you just fixed on frontends. There is probably a few controversial points where I did not know how we could handle prior calculation when it is needed for several fields. So I ended up putting them in a condition testing fields where it is needed. It is a bit ugly I admit but I'm open for suggestions. After this patch series, I have a few other things in queue: - an attempt to better reuse already existing description on stats.c - first attempt to adapt labels with state and health check but I prefer merging things along the way to avoid huge reviews. William Dauchy (6): MINOR: contrib/prometheus-exporter: better output of Not-a-Number CLEANUP: stats: improve field selection for frontend http fields MEDIUM: stats: allow to select one field in `stats_fill_be_stats` MINOR: contrib/prometheus-exporter: use fill_be_stats for backend dump MEDIUM: stats: allow to select one field in `stats_fill_sv_stats` MINOR: contrib/prometheus-exporter: use fill_sv_stats for server dump .../prometheus-exporter/service-prometheus.c | 314 +- include/haproxy/stats.h | 7 +- src/hlua_fcn.c| 5 +- src/stats.c | 987 +++--- 4 files changed, 670 insertions(+), 643 deletions(-) -- 2.29.2
[PATCH 3/6] MEDIUM: stats: allow to select one field in `stats_fill_be_stats`
prometheus approach requires to output all values for a given metric
name; meaning we iterate through all metrics, and then iterate in the
inner loop on all objects for this metric.
In order to allow more code reuse, adapt the stats API to be able to
select one field or fill them all otherwise.
This patch follows what has already been done on frontend side.
>From this patch it should be possible to remove most of the duplicate
code on prometheuse side for the backend
A few things to note though:
- status and uweight field requires prior compute, so I moved that to a
sort of helper `stats_fill_be_stats_computesrv`.
- all ST_F*TIME fields requires some minor compute, so I moved it at te
beginning of the function under a condition.
Signed-off-by: William Dauchy
---
include/haproxy/stats.h | 3 +-
src/hlua_fcn.c | 2 +-
src/stats.c | 357
3 files changed, 257 insertions(+), 105 deletions(-)
diff --git a/include/haproxy/stats.h b/include/haproxy/stats.h
index 8210367ac..6c04f2761 100644
--- a/include/haproxy/stats.h
+++ b/include/haproxy/stats.h
@@ -52,7 +52,8 @@ int stats_fill_li_stats(struct proxy *px, struct listener *l,
int flags,
struct field *stats, int len);
int stats_fill_sv_stats(struct proxy *px, struct server *sv, int flags,
struct field *stats, int len);
-int stats_fill_be_stats(struct proxy *px, int flags, struct field *stats, int
len);
+int stats_fill_be_stats(struct proxy *px, int flags, struct field *stats, int
len,
+ enum stat_field *selected_field);
void stats_io_handler(struct stream_interface *si);
int stats_emit_raw_data_field(struct buffer *out, const struct field *f);
diff --git a/src/hlua_fcn.c b/src/hlua_fcn.c
index aab864370..d13c5344f 100644
--- a/src/hlua_fcn.c
+++ b/src/hlua_fcn.c
@@ -1341,7 +1341,7 @@ int hlua_proxy_get_stats(lua_State *L)
px = hlua_check_proxy(L, 1);
if (px->cap & PR_CAP_BE)
- stats_fill_be_stats(px, STAT_SHLGNDS, stats, STATS_LEN);
+ stats_fill_be_stats(px, STAT_SHLGNDS, stats, STATS_LEN, NULL);
else
stats_fill_fe_stats(px, stats, STATS_LEN, NULL);
lua_newtable(L);
diff --git a/src/stats.c b/src/stats.c
index 161fc6548..81b368663 100644
--- a/src/stats.c
+++ b/src/stats.c
@@ -2259,130 +2259,281 @@ static int stats_dump_sv_stats(struct
stream_interface *si, struct proxy *px, st
return stats_dump_one_line(stats, stats_count, appctx);
}
-/* Fill with the backend statistics. is
- * preallocated array of length . The length of the array
- * must be at least ST_F_TOTAL_FIELDS. If this length is less
- * then this value, the function returns 0, otherwise, it
- * returns 1. can take the value STAT_SHLGNDS.
+/* Helper to compute srv values for a given backend
*/
-int stats_fill_be_stats(struct proxy *px, int flags, struct field *stats, int
len)
+static void stats_fill_be_stats_computesrv(struct proxy *px, int *nbup, int
*nbsrv, int *totuw)
{
- long long be_samples_counter;
- unsigned int be_samples_window = TIME_STATS_SAMPLES;
- struct buffer *out = get_trash_chunk();
const struct server *srv;
- int nbup, nbsrv;
- int totuw;
- char *fld;
-
- if (len < ST_F_TOTAL_FIELDS)
- return 0;
- totuw = 0;
- nbup = nbsrv = 0;
+ *nbup = *nbsrv = *totuw = 0;
for (srv = px->srv; srv; srv = srv->next) {
if (srv->cur_state != SRV_ST_STOPPED) {
nbup++;
if (srv_currently_usable(srv) &&
(!px->srv_act ^ !(srv->flags & SRV_F_BACKUP)))
- totuw += srv->uweight;
+ *totuw += srv->uweight;
}
nbsrv++;
}
HA_RWLOCK_RDLOCK(LBPRM_LOCK, >lbprm.lock);
if (!px->srv_act && px->lbprm.fbck)
- totuw = px->lbprm.fbck->uweight;
+ *totuw = px->lbprm.fbck->uweight;
HA_RWLOCK_RDUNLOCK(LBPRM_LOCK, >lbprm.lock);
+}
- stats[ST_F_PXNAME] = mkf_str(FO_KEY|FN_NAME|FS_SERVICE, px->id);
- stats[ST_F_SVNAME] = mkf_str(FO_KEY|FN_NAME|FS_SERVICE, "BACKEND");
- stats[ST_F_MODE] = mkf_str(FO_CONFIG|FS_SERVICE,
proxy_mode_str(px->mode));
- stats[ST_F_QCUR] = mkf_u32(0, px->nbpend);
- stats[ST_F_QMAX] = mkf_u32(FN_MAX, px->be_counters.nbpend_max);
- stats[ST_F_SCUR] = mkf_u32(0, px->beconn);
- stats[ST_F_SMAX] = mkf_u32(FN_MAX, px->be_counters.conn_max);
- stats[ST_F_SLIM] = mkf_u32(FO_CONFIG|FN_LIMIT, px->fullconn);
- stats[ST_F_STOT] = mkf_u64(FN_COUNTER, px->be_counters.cum_conn);
- stats[ST_F_BIN] = mkf_u64(FN_COUNTER, px->be_counters.bytes_in);
- stats[ST_F_BOUT] = mkf_u64(FN_COUNTER, px->be_counters.bytes_out);
- stats[ST_F_DREQ]
[PATCH 5/6] MEDIUM: stats: allow to select one field in `stats_fill_sv_stats`
prometheus approach requires to output all values for a given metric
name; meaning we iterate through all metrics, and then iterate in the
inner loop on all objects for this metric.
In order to allow more code reuse, adapt the stats API to be able to
select one field or fill them all otherwise.
This patch follows what has already been done on frontend and backend
side.
>From this patch it should be possible to remove most of the duplicate
code on prometheuse side for the server.
A few things to note though:
- state require prior calculation, so I moved that to a sort of helper
`stats_fill_be_stats_computestate`.
- all ST_F*TIME fields requires some minor compute, so I moved it at te
beginning of the function under a condition.
Signed-off-by: William Dauchy
---
include/haproxy/stats.h | 2 +-
src/hlua_fcn.c | 3 +-
src/stats.c | 585 +---
3 files changed, 368 insertions(+), 222 deletions(-)
diff --git a/include/haproxy/stats.h b/include/haproxy/stats.h
index 6c04f2761..6115dca8f 100644
--- a/include/haproxy/stats.h
+++ b/include/haproxy/stats.h
@@ -51,7 +51,7 @@ int stats_fill_fe_stats(struct proxy *px, struct field
*stats, int len,
int stats_fill_li_stats(struct proxy *px, struct listener *l, int flags,
struct field *stats, int len);
int stats_fill_sv_stats(struct proxy *px, struct server *sv, int flags,
-struct field *stats, int len);
+struct field *stats, int len, enum stat_field
*selected_field);
int stats_fill_be_stats(struct proxy *px, int flags, struct field *stats, int
len,
enum stat_field *selected_field);
diff --git a/src/hlua_fcn.c b/src/hlua_fcn.c
index d13c5344f..6dd9efb21 100644
--- a/src/hlua_fcn.c
+++ b/src/hlua_fcn.c
@@ -922,7 +922,8 @@ int hlua_server_get_stats(lua_State *L)
return 1;
}
- stats_fill_sv_stats(srv->proxy, srv, STAT_SHLGNDS, stats, STATS_LEN);
+ stats_fill_sv_stats(srv->proxy, srv, STAT_SHLGNDS, stats,
+ STATS_LEN, NULL);
lua_newtable(L);
for (i=0; i with the server statistics. is
- * preallocated array of length . The length of the array
- * must be at least ST_F_TOTAL_FIELDS. If this length is less
- * then this value, the function returns 0, otherwise, it
- * returns 1. can take the value STAT_SHLGNDS.
+/* Compute server state helper
*/
-int stats_fill_sv_stats(struct proxy *px, struct server *sv, int flags,
-struct field *stats, int len)
+static void stats_fill_sv_stats_computestate(struct server *sv, struct server
*via,
+struct server *ref, enum
srv_stats_state *state)
{
- struct server *via, *ref;
- char str[INET6_ADDRSTRLEN];
- struct buffer *out = get_trash_chunk();
- enum srv_stats_state state;
- char *fld_status;
- long long srv_samples_counter;
- unsigned int srv_samples_window = TIME_STATS_SAMPLES;
-
- if (len < ST_F_TOTAL_FIELDS)
- return 0;
-
- /* we have "via" which is the tracked server as described in the
configuration,
-* and "ref" which is the checked server and the end of the chain.
-*/
- via = sv->track ? sv->track : sv;
- ref = via;
- while (ref->track)
- ref = ref->track;
-
if (sv->cur_state == SRV_ST_RUNNING || sv->cur_state ==
SRV_ST_STARTING) {
if ((ref->check.state & CHK_ST_ENABLED) &&
(ref->check.health < ref->check.rise + ref->check.fall -
1)) {
- state = SRV_STATS_STATE_UP_GOING_DOWN;
+ *state = SRV_STATS_STATE_UP_GOING_DOWN;
} else {
- state = SRV_STATS_STATE_UP;
+ *state = SRV_STATS_STATE_UP;
}
if (sv->cur_admin & SRV_ADMF_DRAIN) {
if (ref->agent.state & CHK_ST_ENABLED)
- state = SRV_STATS_STATE_DRAIN_AGENT;
- else if (state == SRV_STATS_STATE_UP_GOING_DOWN)
- state = SRV_STATS_STATE_DRAIN_GOING_DOWN;
+ *state = SRV_STATS_STATE_DRAIN_AGENT;
+ else if (*state == SRV_STATS_STATE_UP_GOING_DOWN)
+ *state = SRV_STATS_STATE_DRAIN_GOING_DOWN;
else
- state = SRV_STATS_STATE_DRAIN;
+ *state = SRV_STATS_STATE_DRAIN;
}
- if (state == SRV_STATS_STATE_UP && !(ref->check.state &
CHK_ST_ENABLED)) {
- state = SRV_STATS_STATE_NO_CHECK;
+ if (*state == SRV_STATS_STATE_UP && !(ref->check.state &
CHK_ST_ENABLED)) {
+ *state = SRV_STATS_STATE_NO_CHECK;
}
}
[PATCH 6/6] MINOR: contrib/prometheus-exporter: use fill_sv_stats for server dump
use `stats_fill_sv_stats` when possible to avoid duplicating code.
the following metrics have a change of behaviour:
haproxy_server_limit_sessions
haproxy_server_queue_limit
haproxy_server_check_failures_total
haproxy_server_check_up_down_total
haproxy_server_downtime_seconds_total
haproxy_server_current_throttle
haproxy_server_idle_connections_limit
depending on cases, if the limit was not configured or enabled, NaN is
returned instead. It should not be an issue for users, even better than
before as it provides more precise info.
Signed-off-by: William Dauchy
---
.../prometheus-exporter/service-prometheus.c | 143 +-
1 file changed, 7 insertions(+), 136 deletions(-)
diff --git a/contrib/prometheus-exporter/service-prometheus.c
b/contrib/prometheus-exporter/service-prometheus.c
index 12fe3ee90..364d4b6d1 100644
--- a/contrib/prometheus-exporter/service-prometheus.c
+++ b/contrib/prometheus-exporter/service-prometheus.c
@@ -799,8 +799,8 @@ static int promex_dump_srv_metrics(struct appctx *appctx,
struct htx *htx)
struct channel *chn = si_ic(appctx->owner);
struct ist out = ist2(trash.area, 0);
size_t max = htx_get_max_blksz(htx, channel_htx_recv_max(chn, htx));
+ struct field *stats = stat_l[STATS_DOMAIN_PROXY];
int ret = 1;
- uint32_t weight;
double secs;
for (;appctx->st2 < ST_F_TOTAL_FIELDS; appctx->st2++) {
@@ -817,6 +817,9 @@ static int promex_dump_srv_metrics(struct appctx *appctx,
struct htx *htx)
while (appctx->ctx.stats.obj2) {
sv = appctx->ctx.stats.obj2;
+ if (!stats_fill_sv_stats(px, sv, 0, stats,
ST_F_TOTAL_FIELDS, &(appctx->st2)))
+ return -1;
+
if ((appctx->ctx.stats.flags &
PROMEX_FL_NO_MAINT_SRV) && (sv->cur_admin & SRV_ADMF_MAINT))
goto next_sv;
@@ -824,39 +827,6 @@ static int promex_dump_srv_metrics(struct appctx *appctx,
struct htx *htx)
case ST_F_STATUS:
val = mkf_u32(FO_STATUS,
promex_srv_status(sv));
break;
- case ST_F_SCUR:
- val = mkf_u32(0, sv->cur_sess);
- break;
- case ST_F_SMAX:
- val = mkf_u32(FN_MAX,
sv->counters.cur_sess_max);
- break;
- case ST_F_SLIM:
- val =
mkf_u32(FO_CONFIG|FN_LIMIT, sv->maxconn);
- break;
- case ST_F_STOT:
- val = mkf_u64(FN_COUNTER,
sv->counters.cum_sess);
- break;
- case ST_F_RATE_MAX:
- val = mkf_u32(FN_MAX,
sv->counters.sps_max);
- break;
- case ST_F_LASTSESS:
- val = mkf_s32(FN_AGE,
srv_lastsession(sv));
- break;
- case ST_F_QCUR:
- val = mkf_u32(0, sv->nbpend);
- break;
- case ST_F_QMAX:
- val = mkf_u32(FN_MAX,
sv->counters.nbpend_max);
- break;
- case ST_F_QLIMIT:
- val =
mkf_u32(FO_CONFIG|FS_SERVICE, sv->maxqueue);
- break;
- case ST_F_BIN:
- val = mkf_u64(FN_COUNTER,
sv->counters.bytes_in);
- break;
- case ST_F_BOUT:
- val = mkf_u64(FN_COUNTER,
sv->counters.bytes_out);
- break;
case ST_F_QTIME:
secs =
(double)swrate_avg(sv->counters.q_time, TIME_STATS_SAMPLES) / 1000.0;
val = mkf_flt(FN_AVG, secs);
@@ -889,43 +859,6 @@ static int promex_dump_srv_metrics(struct appctx *appctx,
struct htx *htx)
secs =
[PATCH 2/6] CLEANUP: stats: improve field selection for frontend http fields
while working on backend/servers I realised I could have written that in a better way and avoid one extra break. This is slightly improving readiness. also while being here, fix function declaration which was not 100% accurate. this patch does not change the behaviour of the code. Signed-off-by: William Dauchy --- include/haproxy/stats.h | 2 +- src/stats.c | 45 + 2 files changed, 19 insertions(+), 28 deletions(-) diff --git a/include/haproxy/stats.h b/include/haproxy/stats.h index eb72446ae..8210367ac 100644 --- a/include/haproxy/stats.h +++ b/include/haproxy/stats.h @@ -47,7 +47,7 @@ int stats_dump_one_line(const struct field *stats, size_t stats_count, struct ap int stats_fill_info(struct field *info, int len); int stats_fill_fe_stats(struct proxy *px, struct field *stats, int len, - enum stat_field *field); + enum stat_field *selected_field); int stats_fill_li_stats(struct proxy *px, struct listener *l, int flags, struct field *stats, int len); int stats_fill_sv_stats(struct proxy *px, struct server *sv, int flags, diff --git a/src/stats.c b/src/stats.c index e1b350a44..161fc6548 100644 --- a/src/stats.c +++ b/src/stats.c @@ -1712,49 +1712,40 @@ int stats_fill_fe_stats(struct proxy *px, struct field *stats, int len, metric = mkf_u64(FN_COUNTER, px->fe_counters.internal_errors); break; case ST_F_HRSP_1XX: - if (px->mode != PR_MODE_HTTP) - break; - metric = mkf_u64(FN_COUNTER, px->fe_counters.p.http.rsp[1]); + if (px->mode == PR_MODE_HTTP) + metric = mkf_u64(FN_COUNTER, px->fe_counters.p.http.rsp[1]); break; case ST_F_HRSP_2XX: - if (px->mode != PR_MODE_HTTP) - break; - metric = mkf_u64(FN_COUNTER, px->fe_counters.p.http.rsp[2]); + if (px->mode == PR_MODE_HTTP) + metric = mkf_u64(FN_COUNTER, px->fe_counters.p.http.rsp[2]); break; case ST_F_HRSP_3XX: - if (px->mode != PR_MODE_HTTP) - break; - metric = mkf_u64(FN_COUNTER, px->fe_counters.p.http.rsp[3]); + if (px->mode == PR_MODE_HTTP) + metric = mkf_u64(FN_COUNTER, px->fe_counters.p.http.rsp[3]); break; case ST_F_HRSP_4XX: - if (px->mode != PR_MODE_HTTP) - break; - metric = mkf_u64(FN_COUNTER, px->fe_counters.p.http.rsp[4]); + if (px->mode == PR_MODE_HTTP) + metric = mkf_u64(FN_COUNTER, px->fe_counters.p.http.rsp[4]); break; case ST_F_HRSP_5XX: - if (px->mode != PR_MODE_HTTP) - break; - metric = mkf_u64(FN_COUNTER, px->fe_counters.p.http.rsp[5]); + if (px->mode == PR_MODE_HTTP) + metric = mkf_u64(FN_COUNTER, px->fe_counters.p.http.rsp[5]); break; case ST_F_HRSP_OTHER: - if (px->mode != PR_MODE_HTTP) - break; - metric = mkf_u64(FN_COUNTER, px->fe_counters.p.http.rsp[0]); + if (px->mode == PR_MODE_HTTP) + metric = mkf_u64(FN_COUNTER, px->fe_counters.p.http.rsp[0]); break; case ST_F_INTERCEPTED: - if (px->mode != PR_MODE_HTTP) - break; - metric = mkf_u64(FN_COUNTER, px->fe_counters.intercepted_req); + if (px->mode == PR_MODE_HTTP) + metric = mkf_u64(FN_COUNTER, px->fe_counters.intercepted_req); break; case ST_F_CACHE_LOOKUPS: - if (px->mode != PR_MODE_HTTP) - break; - metric = mkf_u64(FN_COUNTER, px->fe_counters.p.http.cache_lookups); + if (px->mode == PR_MODE_HTTP) +
[PATCH] BUILD: ssl: guard SSL_CTX_set_msg_callback with SSL_CTRL_SET_MSG_CALLBACK macro
Hello, another ssl guard patch Ilya From f39f9f69e29570fa43d7db5a0f08ee9395b98d50 Mon Sep 17 00:00:00 2001 From: Ilya Shipitsin Date: Sat, 23 Jan 2021 00:50:59 +0500 Subject: [PATCH] BUILD: ssl: guard SSL_CTX_set_msg_callback with SSL_CTRL_SET_MSG_CALLBACK macro --- src/ssl_sock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/ssl_sock.c b/src/ssl_sock.c index 24a38e47d..2bda3d765 100644 --- a/src/ssl_sock.c +++ b/src/ssl_sock.c @@ -4224,7 +4224,7 @@ int ssl_sock_prepare_ctx(struct bind_conf *bind_conf, struct ssl_bind_conf *ssl_ #endif /* OPENSSL_NO_DH */ SSL_CTX_set_info_callback(ctx, ssl_sock_infocbk); -#if HA_OPENSSL_VERSION_NUMBER >= 0x00907000L +#ifdef SSL_CTRL_SET_MSG_CALLBACK SSL_CTX_set_msg_callback(ctx, ssl_sock_msgcbk); #endif #ifdef HAVE_OPENSSL_KEYLOG -- 2.29.2
[PATCH] spelling fix
Hello, just one fix. Ilya From adc25a39161a95fe6dba7c4a1c723fba223dca82 Mon Sep 17 00:00:00 2001 From: Ilya Shipitsin Date: Sat, 23 Jan 2021 02:11:59 +0500 Subject: [PATCH] CLEANUP: assorted typo fixes in the code and comments This is 16th iteration of typo fixes --- src/cache.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/cache.c b/src/cache.c index f03944faf..3f95195a1 100644 --- a/src/cache.c +++ b/src/cache.c @@ -1198,7 +1198,7 @@ enum act_return http_action_store_cache(struct act_rule *rule, struct proxy *px, * subsequent request having the same primary key will have its accepted * encodings tested upon the cached response's one. * We will not cache a response that has an unknown encoding (not - * explicitely supported in parse_encoding_value function). */ + * explicitly supported in parse_encoding_value function). */ if (cache->vary_processing_enabled && vary_signature) if (set_secondary_key_encoding(htx, object->secondary_key)) goto out; -- 2.29.2
