[ANNOUNCE] haproxy-1.8-rc1 : the last mile

Give some food, drink, disk space, a quiet place, a keyboard and Git to
a developer and he will code forever... All good things must come to an
end, and I decided that it had to be right now. After all, we initially
announced the end of developments around end of September and a release
around October or November. We've missed the September deadline, but I
know by experience that nobody notices missed deadlines as long as they
are not missed by more than one month. And one month ends today.

So what do we have here ? A *preview* of what the final 1.8 will be like.
As a reminder, our -rc don't mean they're totally ready, but that we're
really done with development and only performing the last adjustments,
fixes, cleanups, documentation updates etc and that NEW FEATURES ARE NOT
WELCOME ANYMORE FOR THIS VERSION. There are still some issues (I found
a few after the release) but overall there's enough in various areas to
satisfy the curious. And we needed to merge our various branches to take
the time to fix conflicts and adapt our respective code (mainly to
threads, which were merged first).

In practice, since 1.8-dev3, the following main features were merged :
- multi-thread support : for certain workloads like massive SSL rekeying
it provides comparable performance to multi-process, but with all the
load handled in a single process, hence single health checks and server
states, single stats, single CLI etc. There are some known scalability
limitations coming from arbitrations we had to do for 1.8 and which we
will address during 1.9 (and maybe some before 1.8-final). The feature
is enabled by default on linux2628 and freebsd, and disabled by default
on other targets, though it can be forced enabled using USE_THREAD=1 or
forced disabled using USE_THREAD= (empty string). Once enabled, it's
possible to start several threads in the configuration using the
"nbthread" directive in the global section. It's possible to force to
map threads to CPUs but we're not completely satisfied with the current
configuration options and will be working on them (any feedback is
welcome). Another point is that we tried to start to take a look at
the device detection extensions and it didn't appear trivial enough
to fit in the tight schedule so this was postponed. Their maintainers
are welcome to take a look as they know this much better than anyone
else, and the thread developers will be happy to give some help on the
subject.

Important note: I just found that health-checks are totally broken
(recursive locks and missed unlocks), so please disable checks when
testing threads for now. We'll see how to address this.

- small object cache : this is what I've been calling the "favicon cache"
for several years now. The idea is always the same, when haproxy is
deployed in front of a slow application server having to deliver a few
small static objects, it costs a lot to this server to deliver them. A
small cache of a few megabytes caching small objects for a short time
with zero administration definitely helps here. As we don't want this
cache to cause trouble, it's pessimistic : if any risk is suspected,
an object is not cached ; and by default it caches for a short time
(1 minute I believe) so that even after a failed deployment, it takes
less time to wait than to wake up the LB admin to clear the cache. To
be very clear, this is not meant to replace any real cache you might
already be using. Maybe it could offload it from some dumb files at
best. It's only meant to improve the situation for those not having
a cache. The cache is enabled using "http-request cache-use" and
"http-response cache-store" directives like below (the doc will
come soon) :

- client-facing HTTP/2 : that's HTTP/2 support on the frontend. It's
much better after the completely new rewrite than the first attempt a
few months ago, and in the end I'm really happy with the outcome
despite the pain it was. It's now almost complete, it supports POST,
1xx responses, chunked responses. In fact it's easier to enumerate
what it does not support : CONTINUATION frames are not yet implemented
(I may have found how to do it), PRIORITY frames are ignored (that's
allowed by the spec), there's no equivalent of chunked encoding in
requests, and trailers from the response are discarded. What it needs
most is real world exposure now to spot corner cases. I wanted to
place it on haproxy.org until I failed on the thread problem described
above and had to revert. In order to enable it, simply add
"alpn http/1.1,h2" on a "bind" line present in an HTTP mode frontend,
and if the client advertises ALPN "h2" it will be used, otherwise it
will fall back to HTTP/1.1. You'll need to have 16kB or larger buffers
(that's the default value and may be adjusted using tune.bufsize).
It's only supported over TLS for now. Note, on openssl versions before
1.0.2, you need to use "npn" instead of "alpn", but I don't know how
long browsers will support it.

- TLS1.3 0-RTT done right : while there is a lot of demand for 0-RTT
support everywhere (which people often just call TLS1.3 by the way),
it's important to remember that by default 0-RTT makes TLS vulnerable
to replay attacks and that the upper protocol must take care of this.
The IETF HTTP working group has been working on a draft to define how
to safely map HTTP on top of 0-RTT to provide both performance and
security (https://tools.ietf.org/html/draft-ietf-httpbis-replay-00).
HAProxy 1.8-rc1 is the first server-side component to implement this
draft, and we'll soon run some interoperability tests with a well
known browser which just implemented it as well on the client side.
This can be enabled using openssl-1.1.1 (still in development as well)
and the "allow-0rtt" directive on the bind line.

That's more or less all for the user-visible changes, the rest are important
infrastructure changes supporting this work. That's why it was important to
merge right now, so that we all have a common base to start sorting out the
various issues that will inevitably emerge, and finish the documentation and
the configuration mechanisms. I'm not listing all the things that were
already merged in earlier versions (JSON stats, server-templates, SRV records
etc), I'll try to recap everything for the release.

If you have suggestions (especially on the configuration perspective), feel
free to suggest ideas here on the list so that everyone can participate (and
please use a different thread to address different topics so that participants
are not forced to receive the parts they're not interested in).

Ah last thing. Yes I know it's fun to deploy a fresh new load balancer in
production, and I was about to do it on haproxy.org. I was lucky it took only
2 seconds to enter an endless loop, it's less fun if it happens when you're
driving on your way back home. So use with care, on dedicated servers only,
with non-critical traffic only, and keep an eye on it. Do not hesitate to
report strange things here, we all know it encourages the "me too" behaviour.

I hope we'll be able to quickly sort out the thread+check problem and emit an
rc2, in the worst case in a week or two. Given that the code merge was *much*
faster than anticipated, I wouldn't be surprized if we can release 1.8 by end
of November with everything working (=nobody knows how to break it yet).

Thierry FOURNIER (8):
MINOR: hlua: Add regex class
BUG/MINOR: lua: const attribute of a string is overridden
MEDIUM: threads/lua: Makes the jmpbuf and some other buffers local to the current thread.
MEDIUM: threads/lua: Add locks around the Lua execution parts.
MEDIUM: threads/lua: Ensure that the launched tasks runs on the same threads than me
MEDIUM: threads/lua: Cannot acces to the socket if we try to access from another thread.
MEDIUM: threads/xref: Convert xref function to a thread safe model
MEDIUM: threads/tasks: Add lock around notifications

>Hi Cyril,
>
>On Wed, Nov 01, 2017 at 01:03:42AM +0100, Cyril Bonté wrote:
>>This announcement was exciting enough to take some time to regenerate
>>an up
>>to date HTML documentation ! 1.8-rc1 is now available :
>>http://cbonte.github.io/haproxy-dconv/1.8/configuration.html
>
>Cool, thank you!
>
>> > Have fun,
>> > Willy -- feeling exhausted like a marathoner :-)
>>
>>Great job ! Now it's time to test and track nasty bugs before the
>>final 1.8
>>release ;-)
>
>Yep. And we know certain points already have to be fixed. The real
>great
>thing is to be allowed to sleep a full night for the first time in a
>few
>months ;-)
Have a good and refreshing sleep ;-)

On Wed, Nov 01, 2017 at 10:28:55AM +0000, Aleksandar Lazic wrote:
> Have a good and refreshing sleep ;-)

done :-)

> Thanks for the hard work ;-)
>
> There is now a shiny new docker image with the rc1.
>
> docker run --rm --entrypoint /usr/local/sbin/haproxy me2digital/haproxy18
> -vv

Cool, thanks for doing this. Just FYI, we currently have two issues to
be careful about :
- checks don't work with threads (spinning loop at the first error if
an HTTP check is enabled for example)
- rate counters stored as extra data in stick tables for tracking using
update_freq_ctr_period() enter a spinning loop if threads are *disabled*.

While annoying, it's not huge considering the amount of code merged and the
parallel development that happened. We'll address this ASAP.

BTW I noted last evening that we still didn't add the build options to the
-vv output, we'll do it as well.

Just upgrading the binary from -dev3 to -rc1 however broke my setup:
Turns out that the new object caching code breaks when another filter
(compression) is already enabled (at config parsing stage) - even when
object caching is not enabled itself:

Thanks for reporting, such type of early breakage is indeed expected
after I stressed everyone to merge. We know that the inned parts work
pretty well overall but some integration work is now needed.

You may have to explicitly use the compression filter by the way,
though I have no idea how to do that but I think it's mentionned
somewhere in the config manual. William was about to write some doc
when I interrupted him to get his code, but he'll certainly get back
to this soon.

For the past couple of years, I’ve also been maintaining a base docker image for haproxy. It is interesting to see how other’s structure the build and configuration.

I see that you include a base / default configuration file while I’ve left that completely up to the user to provide one. Given how many different ways people use haproxy, it didn’t seem that there was any one “basic” config that would work beyond a trivial example. I’m curious how useful the configuration you’ve packaged is. I use my image as a base which I then repackage use-case specific configuration files into for deployments and I assume anyone else using the image does the same thing, but I do not have any feedback about that.

> - client-facing HTTP/2 : that's HTTP/2 support on the frontend. It's
> much better after the completely new rewrite than the first attempt a
> few months ago, and in the end I'm really happy with the outcome
> despite the pain it was. It's now almost complete, it supports POST,
> 1xx responses, chunked responses. In fact it's easier to enumerate
> what it does not support : CONTINUATION frames are not yet implemented
> (I may have found how to do it), PRIORITY frames are ignored (that's
> allowed by the spec), there's no equivalent of chunked encoding in
> requests, and trailers from the response are discarded. What it needs
> most is real world exposure now to spot corner cases. I wanted to
> place it on haproxy.org until I failed on the thread problem described
> above and had to revert. In order to enable it, simply add
> "alpn http/1.1,h2" on a "bind" line present in an HTTP mode frontend,
> and if the client advertises ALPN "h2" it will be used, otherwise it
> will fall back to HTTP/1.1.

Actually that is not what I'm seeing.

In ALPN, the client announces the supported protocols, currently for example
http1/1 and h2, and then the server picks a protocol out of that
selection, based
on its own preference.

However, with clients supporting both http/1.1 and h2 the configuration:
alpn http/1.1,h2

always leads to HTTP/1.1 (on both curl and Chrome) here.

I had to turn it around, for HTTP/2 to be actually negotiated:
alpn h2,http/1.1

With the latter configuration, HTTP/2 is actually used.

> "alpn http/1.1,h2" on a "bind" line present in an HTTP mode frontend,

And "alpn h2,http/1.1" does work via HTTP2 in a HTTP mode frontend.

But when the frontend is in TCP mode, and the backend is in HTTP mode,
its looks like the H2 parser is not started even when ALPN negotiates h2, and
the HTTP/1.1 only backend server receives the "PRI" connection request verbatim:

In the HTTP/1.1 world I used to think that even if the frontend is in TCP mode,
when haproxy selects a backend in HTTP mode, it understands that this is gonna
be a HTTP session and it turned on the HTTP hut for all intends and purposes.

Of course, when both front and backend are in TCP mode and we negotiate h2
via NPN or ALPN, we have to leave it alone (just terminate TLS).

But in the "frontend->tcp mode; backend->http mode" case, should we be able to
start the H2 parsing and actually handle this case? Or is this something we are
unable to cover?

I'm certainly able to fix this issue here via configuration, I'm just
not sure if that
is the case for all the use-cases out there?

Now, comment number 3, pretty sure this is actually a bug :)

In my configuration, files transferred via HTTP2 are corrupted with
random content
from memory. I could spot my certificate, some HTTP headers and the content of
/etc/resolv.conf in the HTTP payload. Using HTTP/1.1 (even by a client
side change)
fixes this. Just H2 is affected.

How to reproduce? In my case I'm transferring a 150KB .svg file
through haproxy and
it gets corrupted every time.

>>On Nov 1, 2017, at Nov 1, 3:28 AM, Aleksandar Lazic <[email protected]>
>>wrote:
>>
>>
>>There is now a shiny new docker image with the rc1.
>>
>>docker run --rm --entrypoint /usr/local/sbin/haproxy
>>me2digital/haproxy18 -vv
>>
>For the past couple of years, I’ve also been maintaining a base docker
>image for haproxy. It is interesting to see how other’s structure the
>build and configuration.
>
>I see that you include a base / default configuration file while I’ve
>left that completely up to the user to provide one. Given how many
>different ways people use haproxy, it didn’t seem that there was any
>one “basic” config that would work beyond a trivial example. I’m
>curious how useful the configuration you’ve packaged is. I use my image
>as a base which I then repackage use-case specific configuration files
>into for deployments and I assume anyone else using the image does the
>same thing, but I do not have any feedback about that.
>
>https://hub.docker.com/r/fingershock/haproxy-base/
>
>-Bryan

Well the reason why I use a default config file is that most enterprise
customer mainly don't know how to configure the haproxy.
They know the destination ip:port and on which port the service should
listen.

This makes the usage of that image much easier, from my point of view.
That's the reason why the openshift template exist.

With the environment variable CONFIG_FILE is it possible to use a
complete custom haproxy config file.
This can be provided as you described with -v in docker mode or with
config maps in kubernetes and openshift.

Another point is the logging.

I have added socklog into the image to get haproxy logs to stdout.

Sometimes you have now syslog server where you can send the haproxy logs
therefore the default setup in the image uses the socklog which is
designed to write to stdout and listen to a ip or unix socket.

One of the reason why I have added all this into the image is that the
security level in openshift is quite high, which is good from my point
of view, but due to this fact you can's just use rsyslog image or
something else which requires root privileges.

Another feature is that the prometheus scrapper is there and is used as
sidecar container, at least in my openshift template.

I know there are some options to improve the image, I'm open for
suggestions, issues, pull requests ;-)

I hope I have bring some light to the question why I have build this
image.

On Wed, Nov 01, 2017 at 11:35:30PM +0100, Lukas Tribus wrote:
> In ALPN, the client announces the supported protocols, currently for example
> http1/1 and h2, and then the server picks a protocol out of that
> selection, based on its own preference.

Yep.

> However, with clients supporting both http/1.1 and h2 the configuration:
> alpn http/1.1,h2
>
> always leads to HTTP/1.1 (on both curl and Chrome) here.
>
> I had to turn it around, for HTTP/2 to be actually negotiated:
> alpn h2,http/1.1

Hmmm I think you're right, I've been doing most of my tests with "h2"
only and figured it would be good to propose h1 as well in the mail
announce so that testers don't see connections rejected!

> With the latter configuration, HTTP/2 is actually used.

OK.

> > "alpn http/1.1,h2" on a "bind" line present in an HTTP mode frontend,
>
> And "alpn h2,http/1.1" does work via HTTP2 in a HTTP mode frontend.
>
>
> But when the frontend is in TCP mode, and the backend is in HTTP mode,

I didn't think about this use case.

> its looks like the H2 parser is not started even when ALPN negotiates h2, and
> the HTTP/1.1 only backend server receives the "PRI" connection request verbatim:

That's totally true. H2 is only used if negociated by ALPN *and* the
frontend is in HTTP mode, as I couldn't find any case where we would
not want to use H2 there, so I preferred not to introduce another
option in the frontend.

Yes but here we have to make the choice while installing the mux, it's
important to understand that we *cannot* apply the frontend's switching
rules to the preface which purposely looks like a broken request, then
decide to route it to an HTTP backend. So we have to decide of the protocol
in the frontend.

> Of course, when both front and backend are in TCP mode and we negotiate h2
> via NPN or ALPN, we have to leave it alone (just terminate TLS).

Exactly.

> But in the "frontend->tcp mode; backend->http mode" case, should we be able to
> start the H2 parsing and actually handle this case? Or is this something we are
> unable to cover?

I don't see a way to cover it unfortunately. However I think the HTTP parser
needs to detect the H2 preface and immediately reject it so that we don't
end up with hung requests like this.

> I'm certainly able to fix this issue here via configuration, I'm just
> not sure if that is the case for all the use-cases out there?

We at least need to address it in the configuration. We *may* be able to
address it in the config validity checking : since we're able to detect
http frontends switching to tcp backends and report an error, we might
be able to check for the opposite when one of the frontend's "bind" lines
is configured to support H2, and then emit a warning (since some people
might very well switch to a TCP backend only when ALPN says H2 to offload
the processing somewhere else). However that would leave them with an
unfixable warning and I don't want this either, as TCP->HTTP setups are
used when you want to support multiple protocols on the same port and
ALPN is a perfect example of this. So I think the best would be to just
reject the preface in the backend and report the reason in the logs.

> Now, comment number 3, pretty sure this is actually a bug :)
>
> In my configuration, files transferred via HTTP2 are corrupted with
> random content
> from memory. I could spot my certificate, some HTTP headers and the content of
> /etc/resolv.conf in the HTTP payload. Using HTTP/1.1 (even by a client
> side change)
> fixes this. Just H2 is affected.

I don't know for now, I'll have to try to reproduce. Olivier already
sent me some fixes for mistakes I did in the H2 code (wrong states in
error cases) but that should not affect this. I suspect we're reading
past a buffer in some cases (possibly the measurement of the contiguous
payload in the buffer which occasionally fails).

I think the "cert bundle" feature from 1.7 is broken in 1.8-rc1. My exact config works with 1.7 but says this for 1.8-rc1;

unable to stat SSL certificate from file '/path/to/foo.pem': No such file or directory.

That is, it's attempting to load foo.pem, not foo.pem.rsa or foo.pem.ecdsa like 1.7 does.

I also tried asking the mailing list daemon for help by emailing haproxy+help@formilux.org as the signup confirmation specifies, the full body of that help is just "Hello,". I was hoping to ask the daemon to send me the initial message in this thread so I could reply into the thread properly. Sadly the mailing list archive doesn't show any of the headers I might have injected to get threading working that way, so sorry for breaking the thread but I really tried not to.

I am very excited about many of the new features in 1.8 and am itching to try them.

That's a bug of the post parsing callback, it tries to use the cache with a
filter which is not a cache. I just fix it in the master.

> Thanks for reporting, such type of early breakage is indeed expected
> after I stressed everyone to merge. We know that the inned parts work
> pretty well overall but some integration work is now needed.
>
> You may have to explicitly use the compression filter by the way,
> though I have no idea how to do that but I think it's mentionned
> somewhere in the config manual. William was about to write some doc
> when I interrupted him to get his code, but he'll certainly get back
> to this soon.

It will need a configuration filter keyword for the cache, to define the
explicit order of the filters.

The cache might not work after the compression in the current state of the
filter API.

In file included from ../../ebtree/ebtree.c:21:
.../../ebtree/ebtree.h:469:35: warning: taking address of packed member
'branches' of class or structure 'eb_node' may result in an unaligned
pointer value [-Waddress-of-packed-member]
eb_troot_t *new_left = eb_dotag(&new->branches, EB_LEFT);
^~~~~~~~~~~~~
(a lot of similar)

We've seen this one the other way around in the past, you assing a negative
number to shut it up and it complains on arm where chars are unsigned. I
*seem* to remember that it doesn't complain when entered in hexadecimal
form though, we'll have to try (if you want to, feel free to send a patch
if it works using 0x82 and 0x80).

Same here, though this one is an enum and I would hate to have to start
to use casts for this, casts are only made to secretly hide bugs :-(
I think the pointer could be an unsigned char though. We'll have to
check if it yells somewhere else.

Ah now it starts to report this also for inlines ? It'll get pretty annoying
then as it prevents one from creating all the useful tools at once for later
use :-/ No idea how to shut up this one, maybe in the long term we'll also
need -Wno-unused-function.

Olivier reported them. It's a real pain because it's made like this
on purpose and as usual C language developers are trying to kill C
usage around them by making the language unusable for what it was made
for : manipulating data in a portable way :-( This warning is so much
ridiculous as the so called unaligned pointer is the first member of
the structure! I guess we'll have to hide this one as well but it's
annoying for anyone using ebtree :-/

On Thu, Nov 02, 2017 at 03:58:47PM +0000, Robert Samuel Newson wrote:
> Hi,
>
> I think the "cert bundle" feature from 1.7 is broken in 1.8-rc1. My exact config works with 1.7 but says this for 1.8-rc1;
>
> unable to stat SSL certificate from file '/path/to/foo.pem': No such file or directory.
>
> That is, it's attempting to load foo.pem, not foo.pem.rsa or foo.pem.ecdsa like 1.7 does.

Oh bad, that's totally unexpected. I'm CCing Emeric and Manu, the former
being the SSL maintainer (in case he has a quick idea about it) and the
latter having upgraded a large part of the cert management code, possibly
having an idea about anything that could have gone wrong.

> I also tried asking the mailing list daemon for help by emailing
> haproxy+help@formilux.org as the signup confirmation specifies, the full body
> of that help is just "Hello,". I was hoping to ask the daemon to send me the
> initial message in this thread so I could reply into the thread properly.
> Sadly the mailing list archive doesn't show any of the headers I might have
> injected to get threading working that way, so sorry for breaking the thread
> but I really tried not to.

I was not even aware of the feature :-)

> I am very excited about many of the new features in 1.8 and am itching to try
> them.

As long as you're very careful that's useful. I'm going to issue an rc2 with
the most painful bugs fixed.

It seems to only be some versions of OpenSSL. I’ll go over this again more carefully and keep notes. I was trying out tls 1.3 support as well, so it might be specific to OpenSSL 1.1.1-dev.

Sent from my iPhone

> On 3 Nov 2017, at 22:33, Willy Tarreau <[email protected]> wrote:
>
> Hi Robert,
>
>> On Thu, Nov 02, 2017 at 03:58:47PM +0000, Robert Samuel Newson wrote:
>> Hi,
>>
>> I think the "cert bundle" feature from 1.7 is broken in 1.8-rc1. My exact config works with 1.7 but says this for 1.8-rc1;
>>
>> unable to stat SSL certificate from file '/path/to/foo.pem': No such file or directory.
>>
>> That is, it's attempting to load foo.pem, not foo.pem.rsa or foo.pem.ecdsa like 1.7 does.
>
> Oh bad, that's totally unexpected. I'm CCing Emeric and Manu, the former
> being the SSL maintainer (in case he has a quick idea about it) and the
> latter having upgraded a large part of the cert management code, possibly
> having an idea about anything that could have gone wrong.
>
>> I also tried asking the mailing list daemon for help by emailing
>> haproxy+help@formilux.org as the signup confirmation specifies, the full body
>> of that help is just "Hello,". I was hoping to ask the daemon to send me the
>> initial message in this thread so I could reply into the thread properly.
>> Sadly the mailing list archive doesn't show any of the headers I might have
>> injected to get threading working that way, so sorry for breaking the thread
>> but I really tried not to.
>
> I was not even aware of the feature :-)
>
>> I am very excited about many of the new features in 1.8 and am itching to try
>> them.
>
> As long as you're very careful that's useful. I'm going to issue an rc2 with
> the most painful bugs fixed.
>
> Thanks for the report,
> Willy

On Sat, Nov 04, 2017 at 09:17:23AM +0000, Robert Newson wrote:
> It seems to only be some versions of OpenSSL. I'll go over this again more carefully and keep notes. I was trying out tls 1.3 support as well, so it might be specific to OpenSSL 1.1.1-dev.

It’s only 1.0.1 that’s affected, so I’m inferring that predates support for serving multiple certificate types; it’s not an haproxy regression.

I’ve failed in all attempts to try tls 1.3 though. Haproxy segfaults very soon after startup. I tried several OpenSSL versions.

Sent from my iPhone

> On 4 Nov 2017, at 09:17, Robert Newson <[email protected]> wrote:
>
> It seems to only be some versions of OpenSSL. I’ll go over this again more carefully and keep notes. I was trying out tls 1.3 support as well, so it might be specific to OpenSSL 1.1.1-dev.
>
> Sent from my iPhone
>
>> On 3 Nov 2017, at 22:33, Willy Tarreau <[email protected]> wrote:
>>
>> Hi Robert,
>>
>>> On Thu, Nov 02, 2017 at 03:58:47PM +0000, Robert Samuel Newson wrote:
>>> Hi,
>>>
>>> I think the "cert bundle" feature from 1.7 is broken in 1.8-rc1. My exact config works with 1.7 but says this for 1.8-rc1;
>>>
>>> unable to stat SSL certificate from file '/path/to/foo.pem': No such file or directory.
>>>
>>> That is, it's attempting to load foo.pem, not foo.pem.rsa or foo.pem.ecdsa like 1.7 does.
>>
>> Oh bad, that's totally unexpected. I'm CCing Emeric and Manu, the former
>> being the SSL maintainer (in case he has a quick idea about it) and the
>> latter having upgraded a large part of the cert management code, possibly
>> having an idea about anything that could have gone wrong.
>>
>>> I also tried asking the mailing list daemon for help by emailing
>>> haproxy+help@formilux.org as the signup confirmation specifies, the full body
>>> of that help is just "Hello,". I was hoping to ask the daemon to send me the
>>> initial message in this thread so I could reply into the thread properly..
>>> Sadly the mailing list archive doesn't show any of the headers I might have
>>> injected to get threading working that way, so sorry for breaking the thread
>>> but I really tried not to.
>>
>> I was not even aware of the feature :-)
>>
>>> I am very excited about many of the new features in 1.8 and am itching to try
>>> them.
>>
>> As long as you're very careful that's useful. I'm going to issue an rc2 with
>> the most painful bugs fixed.
>>
>> Thanks for the report,
>> Willy

I've emitted -rc2 last night, though if you were relying on the latest -git
it's probably about the same. So I would be *very* interested in knowing if
you still see the segfault and if so, how to reproduce it!

-rc2 went cpu bound on all threads (nbthread 8 fwiw) where the only thing I changed was haproxy.

B.

> On 4 Nov 2017, at 16:17, Willy Tarreau <[email protected]> wrote:
>
> On Sat, Nov 04, 2017 at 01:33:30PM +0000, Robert Newson wrote:
>> It's only 1.0.1 that's affected, so I'm inferring that predates support for
>> serving multiple certificate types; it's not an haproxy regression.
>>
>> I've failed in all attempts to try tls 1.3 though. Haproxy segfaults very
>> soon after startup. I tried several OpenSSL versions.
>
> I've emitted -rc2 last night, though if you were relying on the latest -git
> it's probably about the same. So I would be *very* interested in knowing if
> you still see the segfault and if so, how to reproduce it!
>
> Willy