On Fri, May 14, 2021 at 11:58 AM Willy Tarreau wrote:
> - interoperability / protocol support: WebSocket over HTTP/2 (RFC8441)
> is now supported on both sides, regardless of the version on the other
> side. The cache now supports the "Vary" header with a few commonly
> used headers,
Hello,
While upgrading from v2.3.x to v2.4.x I noticed a difference of bytes
read in requests http logs with this simple frontend config:
frontend foo
bind 127.0.0.1:8000
http-request return
in v2.3, the logs (%B) tells me 54 bytes, in v2.4, I am getting 49. So
a difference of 5
On Mon, Jul 26, 2021 at 8:35 AM Christopher Faulet wrote:
> The response size reported in the log messages is related to the internal
> representation of the HTTP message. It is a limitation of the current design.
> It
> means this size is not equal to the raw size of the message and may change
`info_field_names` and `stat_field_names` no longer exist and have been
moved in stats.c
To avoid changing this comment, just mention the name of the new table
`info_fields` and `stat_fields`
Signed-off-by: William Dauchy
---
include/haproxy/stats-t.h | 6 +++---
1 file changed, 3 insertions
Signed-off-by: William Dauchy
---
addons/promex/service-prometheus.c | 229 -
include/haproxy/stats-t.h | 1 +
src/stats.c| 4 +
3 files changed, 131 insertions(+), 103 deletions(-)
diff --git a/addons/promex/service-prometheus.c
b
On Mon, Nov 8, 2021 at 1:52 PM Willy Tarreau wrote:
> Just to be sure, is this something you want to merge into 2.5 or is it
> to be queued next ? I'm fine with both, but I prefer to ask as it's not
> just a one-liner and I don't know the impact on promex.
I know Christopher was possibly thinking
Hi Willy,
On Fri, Nov 12, 2021 at 3:48 PM Willy Tarreau wrote:
> I intended to emit the final 2.5 this week-end, but a few users having
> upgraded to the latest 2.4, 2.3 or 2.2 reported strange issues that we
> couldn't reproduce and for which we don't have more info yet. Some seem
> related to c
Signed-off-by: William Dauchy
---
doc/configuration.txt | 21 +
include/haproxy/proxy-t.h | 2 +-
src/mux_h1.c | 3 ++-
src/proxy.c | 1 +
4 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/doc/configuration.txt b/doc/configurat
t = 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/manag
On Sat, Jan 8, 2022 at 3:03 PM Tim Düsterhus wrote:
> Causes issues when applying the patch, because git gets confused and
> believes this to be the patch.
> I tend to indent this type of "literal code block" within my commit
> message with 4 spaces for clarity.
indeed, good point, will fix if I
Hello Christopher,
Thanks for your research,
On Tue, Jan 11, 2022 at 6:55 PM Christopher Faulet wrote:
> Le 1/10/22 à 23:19, Willy Tarreau a écrit :
> > At this point I'm starting to think that we should probably avoid as
> > much as possible to use implicit settings for whatever is dynamic.
> >
On Wed, Jan 12, 2022 at 10:02 AM Christopher Faulet wrote:
> I don't know what is the expected behavior on the stable releases for users.
> Honestly, I've misread you patch and kept in mind you alternative solution...
> But as said, if there is no implicit change (and I'm fine with this
> solutio
Hello Christopher,
On Wed, Jan 12, 2022 at 12:45 PM William Dauchy wrote:
> my approach was to say:
> - remove the implicit behavior
> - then work on the missing commands for the health checks
Do you think we can conclude on it?
--
William
Hello,
I am trying to clarify in which case a tcp connection might be closed
following those rules:
- http-request return
- http-request deny
unless I missed something I have not been able to see the answer within the doc.
General context being, we are using `option http-keep-alive`; also our
hap
Hi Christopher,
Thanks for your reply.
On Tue, Oct 18, 2022 at 10:22 AM Christopher Faulet wrote:
> Since the 2.2, HAProxy responses don't close the client connections in K/A
> mode,
> except for 400-Bad-Request and 408-Request-Time-out. It is the behavior with
> default error messages. Of cour
On Tue, Oct 18, 2022 at 4:15 PM Christopher Faulet wrote:
> On all HTX versions, K/A and close modes are handled in the H1 multiplexer.
> Thus, on these versions, http_reply_and_close() is only closing the stream.
> The
> multiplexer is responsible to close the client connection or not.
ok, than
Hello,
I was looking at maxconn behaviour on frontend side. I understood we
don't trigger accept() once maxconn is reached
https://git.haproxy.org/?p=haproxy.git;a=blob;f=src/listener.c;h=412af94a160662aa11802dd58512c6410c9b56da;hb=HEAD#l920
I wondered whether it would be an acceptable patch to ad
Hello Cedric,
On Mon, Nov 28, 2022 at 8:46 AM Cedric Paillet wrote:
> As described in github issue #1312, the first intention of patch 42d7c402d
> was to aggregate haproxy_server_check_status. But we aggregated
> haproxy_server_status instead.
> To fix that, rename haproxy_backend_agg_server_chec
On Tue, Nov 29, 2022 at 11:52 AM William Dauchy wrote:
> On Mon, Nov 28, 2022 at 8:46 AM Cedric Paillet wrote:
> > As described in github issue #1312, the first intention of patch 42d7c402d
> > was to aggregate haproxy_server_check_status. But we aggregated
> > haproxy_
On Tue, Dec 6, 2022 at 3:27 AM Christopher Faulet wrote:
> IMHO, we should keep the current metric and its description should be updated
> to
> mention it is deprecated. This way, we will be able to remove it in the 2.9 or
> 3.0. This means we should find new names for the aggregated servers stat
On Tue, Oct 18, 2022 at 4:15 PM Christopher Faulet wrote:
> On all HTX versions, K/A and close modes are handled in the H1 multiplexer.
> Thus, on these versions, http_reply_and_close() is only closing the stream.
> The
> multiplexer is responsible to close the client connection or not.
>
> On pr
Hi Christopher,
On Fri, Feb 3, 2023 at 7:59 PM William Dauchy wrote:
> On Tue, Oct 18, 2022 at 4:15 PM Christopher Faulet
> wrote:
> > On all HTX versions, K/A and close modes are handled in the H1 multiplexer.
> > Thus, on these versions, http_reply_and_close() is only
Hi Christopher,
Thanks for your answer.
On Tue, Feb 7, 2023 at 9:09 AM Christopher Faulet wrote:
> The tarpit action is final. So it cannot be used in addition to a return or a
> deny action. For the wait-for-body action, indeed, it will wait for the body
> or
> a full buffer for 1 second. Thus
Hi Craig,
Thank you for your patch.
Do you think you could come back with a patch which is only modifying
the section you want? It seems you did a change on the full file
instead which makes the review quite hard.
--
William
Signed-off-by: William Dauchy
---
src/proto_tcp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/proto_tcp.c b/src/proto_tcp.c
index a9d5229c9..044ade430 100644
--- a/src/proto_tcp.c
+++ b/src/proto_tcp.c
@@ -906,9 +906,9 @@ int tcp_bind_listener(struct listener *listener,
On Wed, Feb 12, 2020 at 03:32:07PM +0100, Willy Tarreau wrote:
> I'd do it differently so that we neither try nor report an error if
> the default mss was not set. Indeed, if it already failed earlier,
> we already had an issue, so no need to fail again. So if you agree
> I'll change it to :
>
>
we check ns variable but we don't use it later
Signed-off-by: William Dauchy
---
src/namespace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/namespace.c b/src/namespace.c
index 89a968e36..3536629bc 100644
--- a/src/namespace.c
+++ b/src/namespace.c
@@ -120,7 +
Two minor patches for namespace.
William Dauchy (2):
BUG/MINOR: namespace: avoid closing fd when socket failed in
my_socketat
CLEANUP: namespace: remove uneeded ns check in my_socketat
src/namespace.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--
2.25.0
we cannot return right after socket opening as we need to move back to
the default namespace first
this should fix github issue #500
this might be backported to all version >= 1.6
Fixes: b3e54fe387c7c1 ("MAJOR: namespace: add Linux network namespace
support")
Signed-off-by: W
On Thu, Feb 13, 2020 at 01:31:51AM +0500, Илья Шипицин wrote:
> we "use" it.
> depending on true/false we either return -1 or not
I guess it is present in the first condition to be able to access
`ns->fd` safely in setns; but the second condition does not acces `ns`
later.
--
William
On Thu, Feb 13, 2020 at 07:48:03AM +0100, Willy Tarreau wrote:
> For me it's different, it's not related to the fact that it's used
> later but to the fact that we only need to undo the namespace change
> if it was changed in the first call. Indeed "ns" is not null only
> when the caller wants to s
as agreed a few months ago, enable strict-limits for v2.3
Signed-off-by: William Dauchy
---
src/cfgparse-global.c | 2 --
src/haproxy.c | 17 +++--
2 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/src/cfgparse-global.c b/src/cfgparse-global.c
index 0e6905976
as agreed a few months ago, enable strict-limits for v2.3
update configuration manual accordingly
Signed-off-by: William Dauchy
---
doc/configuration.txt | 11 +--
src/cfgparse-global.c | 2 --
src/haproxy.c | 17 +++--
3 files changed, 12 insertions(+), 18
On Sat, Mar 28, 2020 at 7:29 PM Lukas Tribus wrote:
> master is still for 2.2 which is in development. If you want to target
> v2.3, you have to wait until 2.2 is released.
oh true, I'm mixing versions, probably because we already started to
deploy part of v2.2...
Sorry for that, please ignore t
Hello Willy,
On Mon, Apr 27, 2020 at 7:29 PM Willy Tarreau wrote:
> just a quick note, be careful with -dev6, monitor your FDs from time
> to time. Today it caused an outage on haproxy.org after all FDs were
> in use. Sadly we had skipped a number of -dev in the past, jumping
> from something bet
On Tue, Apr 28, 2020 at 8:50 PM Willy Tarreau wrote:
> So just to let you know, we could finally nail the issue down to a
> change I did on mux-h1 at the end of dev4 (so dev5 is also affected).
> Only front connections dying in a dirty way were affected (i.e. users
> disappearing from the net afte
are
killed")
being the origin of this new behaviour.
So if I understand the later correctly, it seems that it was more a
matter of chance that we did not saw the issue earlier.
My patch proposes to force clean idle connections in the two following
cases:
- we set a (still running) server
pproach is most likely not the good one but feel free to advise so
I may improve it.
William Dauchy (1):
BUG/MEDIUM: connections: force connections cleanup on server changes
include/proto/server.h | 1 +
src/server.c | 37 -
2 files changed, 37 insert
On Sat, May 02, 2020 at 09:52:36PM +0200, William Dauchy wrote:
> +void srv_cleanup_connections(struct server *srv)
> +{
> + struct connection *conn;
> + int did_remove;
> + int i;
> + int j;
> +
> + HA_SPIN_LOCK(OTHER_LOCK, &idle_conn_srv_
Hello Olivier,
On Sat, May 02, 2020 at 10:11:26PM +0200, Olivier Houchard wrote:
> And I think your fix is correct, so I will apply it as-is. However, I
> think it should be applied to previous branches, that also had idle
> connection pools. It is probably less noticable before 079cb9af22da6,
> b
On Sat, May 02, 2020 at 10:17:01PM +0200, Olivier Houchard wrote:
> If that's the only change you have for a v2, don't bother, I already
> integrated it in what I plan to push :)
ok, thanks a lot!
--
William
this patch should be backported where commit 6318d33ce625
("BUG/MEDIUM: connections: force connections cleanup on server changes")
will be backported, that is to say v1.9 to v2.1.
Fixes: 6318d33ce625 ("BUG/MEDIUM: connections: force connections cleanup
on server changes")
Si
Hello Olivier,
Sorry for this one, I originally did update the server.h file, but I
don't know why I forgot to add it in my patch submission :/
then I saw you fixed it while pushing my commit, thank you for this.
On Mon, May 04, 2020 at 01:52:40PM +0200, William Dauchy wrote:
> this patc
On Mon, May 04, 2020 at 01:56:10PM +0200, William Dauchy wrote:
> Sorry for this one, I originally did update the server.h file, but I
> don't know why I forgot to add it in my patch submission :/
> then I saw you fixed it while pushing my commit, thank you for this.
I'm talki
Hello,
Thank you for this release update!
On Tue, May 5, 2020 at 11:46 PM Willy Tarreau wrote:
> HAProxy 2.2-dev7 was released on 2020/05/05. It added 205 new commits
> after version 2.2-dev6.
>
> The most visible changes in this version is the rework of the health checks
> that was started by G
sts were
performed on >= v5.7rc4 as the time of writing.
it introduces three build parameters:
- USE_IO_URING
- IO_URING_INC
- IO_URING_LIB
Signed-off-by: William Dauchy
---
Makefile | 10 +-
doc/io_uring.txt | 18 +++
include/proto/ssl_load.h | 23
include/types
se of async, but that's
another story.
see also https://kernel.dk/io_uring.pdf for more info about io_uring.
William Dauchy (1):
MEDIUM: ssl: add alternative way to load certificates with io_uring
Makefile | 10 +-
doc/io_uring.txt | 18 +++
include/proto/ssl_lo
On Sat, May 09, 2020 at 12:48:30PM +0200, Willy Tarreau wrote:
> I prefer to warn, this is long and only of interest for those who code,
> so don't force yourself to digest this if not necessary :-)
nice summary as always!
> In the end I think that would leave us more or less with this:
> - cre
Hello,
Here are a few minor fixes on pollers as I'm currently spending some
time in this area.
William Dauchy (3):
BUG/MINOR: pollers: remove uneeded free in global init
BUG/MINOR: select: remove uneeded free in thread init
CLEANUP: select: enhance readability in init
src/ev_p
we wrongly free `tmp_evts[DIR_RD]` in error case.
it could be backported from v1.8 to v2.1.
Fixes: d4604adeaa8c ("MAJOR: threads/fd: Make fd stuffs thread-safe")
Signed-off-by: William Dauchy
---
src/ev_select.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff -
while reading the code, I thought it was clearer to put one instruction
per line as it is mostly done elsewhere
Signed-off-by: William Dauchy
---
src/ev_select.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/ev_select.c b/src/ev_select.c
index 167bb7eb7
lper for all threads, making those free uneeded.
Only poll and select are affected by this very minor issue.
it could be backported from v1.8 to v2.1.
Fixes: cd7879adc2c4 ("BUG/MEDIUM: threads: Run the poll loop on the main
thread too")
Signed-off-by: William Dauchy
---
src/ev_poll.
Hello Willy,
Thank you for your feedbacks.
On Sat, May 9, 2020 at 6:39 AM Willy Tarreau wrote:
> Your work could be extended to other files, like errorfiles, maps, ACLs,
> etc. However with the config parser being very linear, it's extremely
> unlikely that we could actually benefit from this in
Hello William L.
Thank you for your answer.
On Mon, May 11, 2020 at 1:01 PM William Lallemand
wrote:
> I'm wondering if we coud have the timing directly in the logs or on the
> CLI, because I'm actually also doing this kind of things, and people
> could probably optimize the loading if they coul
On Mon, May 11, 2020 at 5:32 PM William Lallemand
wrote:
> By removing, it just means:
> - In the case of a directory there is basicaly nothing to do but remove
> the bundle code, everything will be loaded as usual, it will just be
> done in separate SSL_CTX.
> - In the configuration, if you s
On Wed, May 13, 2020 at 11:50:50AM +0200, Willy Tarreau wrote:
> It's not a bug, it's just a way to ensure a common error path undoes
> everything that was done before reaching it. If another operation is
> added after the DIR_WR malloc, it will only have to add its own undo
> operation to the fail
On Wed, May 13, 2020 at 03:52:54PM +0200, Willy Tarreau wrote:
> > This one breaks clang builds because it removes the fail_revt label but it
> > is
> > still declared as a local label, and clang errors on it.
>
> Ah crap! I didn't notice this part which didn't appear in the context
> of the patc
:
include/types/ssl_sock.h:240:16: error: field ‘early_buf’ has incomplete type
240 | struct buffer early_buf; /* buffer to store the early data
received */
no backport needed.
Fixes: c0cdaffaa338 ("REORG: ssl: move ssl_sock_ctx and fix
cross-dependencies issues")
Signed-of
Hello William L.,
On Wed, Dec 4, 2019 at 4:24 PM PR Bot wrote:
> Patch title(s):
>MINOR: add fetch 'ssl_c_verified_chain'
>Merge branch 'master' of https://github.com/haproxy/haproxy
> Link:
>https://github.com/haproxy/haproxy/pull/396
> Edit locally:
>wget https://github.com/hapr
On Mon, May 18, 2020 at 3:58 PM William Lallemand
wrote:
> I suppose it was put in a PKCS7 container to be able to distinguish each
> DER part of the chain easily? So It can be used by an external tool. I'm not
> sure of what is done with the result of this.
>
> The two patches seem to have differ
Hi Arjen,
On Mon, May 18, 2020 at 6:02 PM Arjen Nienhuis wrote:
> I used PKCS7 because I did not know how to parse concatenated blobs.
Mathilde, how did we planned to use it? :)
> I think you should use SSL_get_peer_cert_chain because:
> - BoringSSL has no SSL_get0_verified_chain.
> - For debug
On Wed, May 27, 2020 at 12:42 PM William Lallemand
wrote:
> So in my opinion we should do the same, and set the minimum version to
> TLSv12 by default on bind lines. It's still configurable with
> min-ssl-ver if you want the support for prior TLS versions.
> Does anybody have any objections?
Even
Hello Christopher,
On Fri, May 29, 2020 at 9:02 AM Christopher Faulet wrote:
> I was able to reproduce the bug. Thanks for the reproducer. I've fixed it. It
> should be ok now.
I believe you are referring to
https://git.haproxy.org/?p=haproxy.git;a=commit;h=56192cc60b786f2c82925411d8b2ccd7d9f97d
On Fri, May 29, 2020 at 4:31 PM William Lallemand
wrote:
> William Dauchy fixed the connection idle cleanup upon a server maintenance or
> an ip/port change.
> BUG/MEDIUM: connections: force connections cleanup on server changes
it seems like I broke something with this commit,
As explained by Christopher on github issue #665:
In 2.2, srv->idle_conns and srv->safe_conns are thread-safe lists. But
not in 2.1. So the patch must be reverted or the lists must be changed
to use mt_list instead. The same must be done in 2.0, but the mt_list
does not exist on this version.
I ch
As explained by Christopher on github issue #665:
In 2.2, srv->idle_conns and srv->safe_conns are thread-safe lists. But
not in 2.1. So the patch must be reverted or the lists must be changed
to use mt_list instead. The same must be done in 2.0, but the mt_list
does not exist on this version.
I ch
On Tue, Jun 2, 2020 at 12:13 PM William Dauchy wrote:
> it seems like I broke something with this commit, but I did not have
> it in v2.2
small followup:
Sorry for that one, the backport was not exactly as I thought, and so
no test were done before release outside of 2.2 branch:
- a
Hello Arthur,
On Wed, Jun 3, 2020 at 11:38 AM Artur wrote:
> What is the risk to trigger this bug in real life ? How to avoid it
> before the next haproxy release ?
> In my setup haproxy 2.1.5 has threads enabled by default (Debian Buster
> backports).
You will trigger this issue if you are in t
Hello Igor,
On Thu, Jun 11, 2020 at 5:25 PM Igor Pav wrote:
> We got a very high CPU constantly while using 2.2dev. Any suggestion? Thanks.
Do you have more inputs of what you are doing to trigger that?
does it end at some point with an abort? e.g do you have in logs
things like "Thread X is abo
Hi,
On Thu, Jun 11, 2020 at 1:10 PM Willy Tarreau wrote:
> Sure but what I wanted to say was that travis seems to be the only
> point experiencing such difficulties and we don't know how it works
> nor what are the rules in place.
I don't know whether this is related to the issue described here
Hello,
On Sun, Jun 14, 2020 at 7:40 AM Willy Tarreau wrote:
> On Sun, Jun 14, 2020 at 12:37:43AM +0200, Tim Duesterhus wrote:
> > careful with this one: I don't know whether it's safe to simply free the
> > expression there or whether I need to somehow check whether there actually
> > is some exp
hat the configuration above no longer crashes.
> It has also been verified that the configuration in
> ff78fcdd7f15c8626c7e70add7a935221ee2920c
> does not leak.
Reported-by: William Dauchy
> ---
> src/haproxy.c | 1 -
> src/vars.c| 7 +++
> 2 files changed, 7 insertions(+), 1 deletion(-)
Best,
--
William
Hi Igor,
On Thu, Jul 2, 2020 at 9:57 AM Igor Pav wrote:
> By using dev11, the CPU consumption drops a lot, but when connections
> reach ~1000, the CPU would still go high, remove the 0rtt-rejected
> from conf, the CPU becomes normal...
if you have the opportunity to test the last HEAD of the rep
Hello Willy,
On Sat, Jul 4, 2020 at 8:11 AM Willy Tarreau wrote:
> HAProxy 2.2-dev12 was released on 2020/07/04. It added 72 new commits
> after version 2.2-dev11.
maybe the package is being uploaded but I can't find it on
http://www.haproxy.org/download/2.2/src/devel/
> - for developers, bui
On Fri, Jul 17, 2020 at 3:33 PM Willy Tarreau wrote:
> We'll try to emit more frequent -dev releases from now on, typically
> every 2 weeks, as the end of the 2.2 cycle showed that it improves accuracy
> in bug reports, brings less risks to users, and shortens the time needed to
> write the announ
it seems like `actually` was wrongly used instead of `currently`
Signed-off-by: William Dauchy
---
contrib/spoa_server/README | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/spoa_server/README b/contrib/spoa_server/README
index f654a2321..a6c696c78 100644
--- a
ment.
This should fix github issue #702
This should be backported to >= v2.2
Signed-off-by: William Dauchy
---
contrib/spoa_server/ps_python.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/spoa_server/ps_python.c b/contrib/spoa_server/ps_python.c
index 00cb0e
On Mon, Aug 3, 2020 at 10:31 PM Artur wrote:
> It would be nice to have a Debian Stretch package for the current LTS
> 2.2 branch in backports. It seems it's not available for now.
CCing Vincent who is maintaining those packages.
--
William
%[ssl_c_chain_der,hex]
One can parse it with any lib accepting ASN.1 DER data, such as in go:
bin, err := encoding/hex.DecodeString(cert)
certs_parsed, err := x509.ParseCertificates(bin)
Cc: Arjen Nienhuis
Signed-off-by: Mathilde Gilles
Signed-off-by: William Dauchy
---
doc/configuration.txt
trivial commit, does not change the code behaviour
Signed-off-by: William Dauchy
---
src/ssl_utils.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/ssl_utils.c b/src/ssl_utils.c
index 510b5da80..0a12fea5b 100644
--- a/src/ssl_utils.c
+++ b/src/ssl_utils.c
haproxy, and in which way. Indeed, as pointed by Emeric in
https://www.mail-archive.com/haproxy@formilux.org/msg37380.html
`SSL_get_peer_cert_chain` returns NULL in case of resumed session.
Thanks,
William Dauchy (2):
CLEANUP: ssl: ssl_sock_crt2der semicolon and spaces
MINOR: ssl: add
Hello William,
Thanks for your quick answer.
On Wed, Aug 5, 2020 at 2:41 PM William Lallemand wrote:
> I don't know if this is possible to fix it, but I think must of the SSL
> fetches have
> the problem.
ok makes sense in that case. So for now I assume there is no easy way
to get the informat
trivial commit, does not change the code behaviour
Signed-off-by: William Dauchy
---
src/ssl_utils.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/ssl_utils.c b/src/ssl_utils.c
index 510b5da80..0a12fea5b 100644
--- a/src/ssl_utils.c
+++ b/src/ssl_utils.c
%[ssl_c_chain_der,hex]
One can parse it with any lib accepting ASN.1 DER data, such as in go:
bin, err := encoding/hex.DecodeString(cert)
certs_parsed, err := x509.ParseCertificates(bin)
Cc: Arjen Nienhuis
Signed-off-by: Mathilde Gilles
Signed-off-by: William Dauchy
---
Changes:
v2: add return
On Wed, Aug 5, 2020 at 3:20 PM Emeric Brun wrote:
> I think this code could be useful to declare also a "ssl_s_chain_der" using
> minor changes as this is done on ssl_c_serial:
true, I can do a v3 to handle this.
--
William
%[ssl_c_chain_der,hex]
One can parse it with any lib accepting ASN.1 DER data, such as in go:
bin, err := encoding/hex.DecodeString(cert)
certs_parsed, err := x509.ParseCertificates(bin)
Cc: Arjen Nienhuis
Signed-off-by: Mathilde Gilles
Signed-off-by: William Dauchy
---
v2:
- add missing check
trivial commit, does not change the code behaviour
Signed-off-by: William Dauchy
---
src/ssl_utils.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/ssl_utils.c b/src/ssl_utils.c
index 510b5da80..0a12fea5b 100644
--- a/src/ssl_utils.c
+++ b/src/ssl_utils.c
trivial commit, does not change the code behaviour
Signed-off-by: William Dauchy
---
src/mux_fcgi.c | 2 +-
src/mux_h2.c | 2 +-
src/ring.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mux_fcgi.c b/src/mux_fcgi.c
index 875049884..ab9ddf095 100644
--- a/src
On Tue, Aug 11, 2020 at 11:36 AM William Lallemand
wrote:
> I just pushed this fix on top on your patch, the sk_X509_pop_free() was
> provoking a double free in the session release.
>
> e3a5f84 BUG/MINOR: ssl: double free w/ smp_fetch_ssl_x_chain_der()
ok sorry for that and thanks for the fix. St
Hello Pierre,
On Fri, Aug 21, 2020 at 7:46 PM Pierre Cheynier wrote:
> We're running HAProxy 2.2.2.
> It turns out logging requests paths using "%HP" var produce a different
> results on H1 vs. H2.
>
> H1: /path
> H2: https://hostname.domain/path (< I consider this one buggy)
>
> No idea where d
Hello,
I'm trying to understand `ssl_fc_has_early` fetcher behavior as I'm
unable to find a single request where it returns 1.
Our config has 0rtt enabled and it is as follow:
```
global
log 127.0.0.1 format rfc5424 local0 info
daemon
stats socket /var/lib/haproxy/stats level admin m
On Wed, Sep 9, 2020 at 10:48 AM William Dauchy wrote:
> I'm trying to understand `ssl_fc_has_early` fetcher behavior as I'm
> unable to find a single request where it returns 1.
(sorry, forgot to mention, all of these tests were done on v2.2.x)
--
William
Hello Willy,
Thank you for your answer,
On Wed, Sep 9, 2020 at 4:39 PM Willy Tarreau wrote:
> If I remember well, the principle consists in detecting whether or not
> the request was received using TLS early data (0-rtt) before the handshake
> was completed. The problem is that early data may tr
> > That seems strange indeed but looking at the code that's what I'm
> > seeing. Was your access to ssl_fc_has_early placed before or after the
> > rule above ? If it's after it must indeed report false.
fetcher is placed before the rule
> > I seem to remember there was one but can't find it, so
issue #872
this should probably be backported in >= v2.2 in order to encourage
people to move away from bundle certificates loading.
Signed-off-by: William Dauchy
---
doc/configuration.txt | 7 ++-
doc/management.txt| 4
2 files changed, 10 insertions(+), 1 deletion(-)
diff --
`tcpcheck_agent_expect_reply` expects "fail" not "failed"
This should fix github issue #876
This can be backported to all maintained versions (i.e >= 1.6) as of
today.
Signed-off-by: William Dauchy
---
doc/configuration.txt | 2 +-
1 file changed, 1 insertion(+), 1 de
this condition is never true as we either break or goto error, so those
two lines could be removed in the current state of the code.
this is fixing github issue #862
Signed-off-by: William Dauchy
---
src/ssl_crtlist.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/ssl_crtlist.c b
this will be useful if we want to be able to call it at runtime through
the CLI. Not 100% mandatory but might be a good protection for future
use.
Signed-off-by: William Dauchy
---
src/ssl_sock.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/src
facilitate the review.
`ssl_sock_prepare_srv_ctx` protection is not mandatory but I found it
safer while writing my patch.
- the last one is adding the new command. I'm not 100% sure of the
consequences of`prepare_srv` and `destroy_srv` but from what I read
and tested, it seems ok.
Wi
so we can reuse it later
Signed-off-by: William Dauchy
---
include/haproxy/server.h | 1 +
src/cfgparse-ssl.c | 31 ++-
src/server.c | 21 +
3 files changed, 24 insertions(+), 29 deletions(-)
diff --git a/include/haproxy
1 - 100 of 414 matches
Mail list logo
