Dear all,
I just saw in the release notes for 2.8 that an automatic OCSP renewal
is now included and I would like to get rid of my manual scripts that
are currently injecting the OCSP information.
I checked a little bit the documentation here:
On Wed, May 31, 2023 at 04:54:57PM +, Tristan wrote:
> Congratulations to the team at large for the release!
> There's definitely been more improvements and fixes than meets the eye from
> the release notes alone!
>
> On 31/05/2023 16:14, Willy Tarreau wrote:
>
> > - QUIC: it has been
Congratulations to the team at large for the release!
There's definitely been more improvements and fixes than meets the eye
from the release notes alone!
On 31/05/2023 16:14, Willy Tarreau wrote:
- QUIC: it has been running almost flawlessly for a year on haproxy.org,
and totally
On Wed, May 31, 2023 at 06:10:37PM +0200, Tim Düsterhus wrote:
> Willy,
>
> On 5/31/23 17:14, Willy Tarreau wrote:
> > HAProxy 2.8.0 was released on 2023/05/31. It added 27 new commits
> > after version 2.8-dev13.
>
> Congratulations! Enjoy the release party :-)
Thanks ;-)
> Best regards
> Tim
Willy,
On 5/31/23 17:14, Willy Tarreau wrote:
HAProxy 2.8.0 was released on 2023/05/31. It added 27 new commits
after version 2.8-dev13.
Congratulations! Enjoy the release party :-)
Best regards
Tim Düsterhus
PS: Wouldn't be a "Tim email" without some minor nit. Just FYI: I made a
small
Hi,
HAProxy 2.8.0 was released on 2023/05/31. It added 27 new commits
after version 2.8-dev13.
Only a small minor issues were addressed this time, the rest was
mostly doc polishing and cleanups. 2.8 is entering LTS status and will
be supported till 2028-Q2, and 2.9-dev0 was just created to
Is it? In all the programming languages I use, the colon is followed by
the return type (which for iif is str).
my claim of mainstream-ness, was mainly meaning the ": in => out" order
(one example would be most ML languages, Typescript, Java...) as opposed
to ": out <= in" which I haven't
Tristan,
On 5/31/23 12:28, Tristan wrote:
If fetches already have the output type after the colon, then the
converter should not have the input type after the colon, i.e.
iif(str,str): bool => str
is confusing, because it looks like it returns a bool, ... I guess?
While this is mainly
If fetches already have the output type after the colon, then the
converter should not have the input type after the colon, i.e.
iif(str,str): bool => str
is confusing, because it looks like it returns a bool, ... I guess?
While this is mainly a feelings thing, I'd say that it is more
Hi all,
On Wed, May 31, 2023 at 10:02:45AM +0200, Tim Düsterhus wrote:
> Aurelien,
>
> On 5/31/23 09:57, Aurelien DARRAGON wrote:
> > would not fit properly with existing representation for converters
> > within the doc
> >
> > > iif(str,str): str <= bool
> >
> > and
> >
> > > iif(str,str):
Aurelien,
On 5/31/23 09:57, Aurelien DARRAGON wrote:
would not fit properly with existing representation for converters
within the doc
iif(str,str): str <= bool
and
iif(str,str): bool => str
could be good candidates (fetches are already represented using
"name(arg) : out"), although
> What I would find clear:
>
> bool => iif(str,str) => str
You're right Tim
But in the long term it could be great to share a common output format
with the doc as well (to find all relevant info from -dKcnv in the doc,
and vice versa)
While
> bool => iif(str,str) => str
and
> bool |
Hi
On 5/30/23 22:09, Aurelien DARRAGON wrote:
$> haproxy -f test.conf -dKcnv | grep nbsrv
iif(string,string): str => bool
iif(string,string): bool => str
I don't rely on it, but frankly I find both variants confusing, because
it does not follow the logical processing order.
What I
13 matches
Mail list logo
