Re: [ANNOUNCE] haproxy-2.6-dev11
вт, 24 мая 2022 г. в 10:47, Willy Tarreau : > Hi Ilya, > > On Tue, May 24, 2022 at 09:53:01AM +0500, ??? wrote: > > Hello, > > > > can we please address https://github.com/haproxy/haproxy/issues/1585 > before > > final 2.6 ? > > I thought it was since I replied it was an FP but OK, I pushed a patch > to silence it. > thanks! > > Thanks, > Willy >
Re: [ANNOUNCE] haproxy-2.6-dev11
Hi Ilya, On Tue, May 24, 2022 at 09:53:01AM +0500, ??? wrote: > Hello, > > can we please address https://github.com/haproxy/haproxy/issues/1585 before > final 2.6 ? I thought it was since I replied it was an FP but OK, I pushed a patch to silence it. Thanks, Willy
Re: [ANNOUNCE] haproxy-2.6-dev11
Hello,
can we please address https://github.com/haproxy/haproxy/issues/1585 before
final 2.6 ?
Ilya
сб, 21 мая 2022 г. в 13:11, Willy Tarreau :
> Hi,
>
> HAProxy 2.6-dev11 was released on 2022/05/20. It added 106 new commits
> after version 2.6-dev10.
>
> Yes, there were still too many changes for a final version, that's often
> like this when getting close to a release. And I couldn't finish the
> renaming of the confusing stuff in the conn_stream layer, for which I'll
> rely on Christopher's help next week. I now understand the trouble some
> developers face when creating an applet and why the only practical
> solution is to copy-paste existing stuff, because even some of the
> existing functions' comments are ambiguous if you stumble on them with
> the wrong idea of what they do, and I absolutely want to address this
> for the release, or it will further complicate development in new
> versions, or maintenance of 2.6 if we rename later.
>
> Most of the changes are of minor importance, or bug fixes though, but
> some are particularly interesting:
>
> - on the SSL front, a few global settings were added to configure the
>ssl-providers that come with OpenSSL 3 to replace the engines. At this
>point it's not totally clear to me how this will evolve, but since
>these are just global settings that are very likely to become necessary
>mid-term, it's better if they're readily available.
>
> - QUIC now provides a number of counters of retries, errors etc, and
>finally supports the Retry mechanism, which is the QUIC equivalent of
>the TCP SYN cookies. These are used to validate a client's connection
>request and make sure it's not a spoofed packet. They can be forced, or
>will be automatically enabled when a configurable number of incoming
>connections are not yet confirmed. This is done via the global
>"tune.quic.retry-threshold" parameter. BTW I'm just seeing that it's
>not documented yet; Fred, please do not forget to update it!
>
> - outgoing applets now support delayed initialization. I know it's a bit
>late for merging this but it addresses a long-existing problem with the
>peers and that could possibly be further emphasized with the http
> client.
>The problem was that outgoing applets were only created on the thread
>that required them, and for peers it was created during config parsing,
>thus all outgoing applets were on thread 1, possibly eating a lot of
>CPU on this thread. That's the issue that Maciej Zdeb reported a month
>ago. Maciej tried to address this but there was a chicken-and-egg issue
>that made it impossible to create the applets on another thread. Now
>that they can be initialized later, it's possible to schedule them on
>any thread, and Maciej's patches could be integrated as well, so the
>peers will no longer aggregate mostly on one thread.
>
> - a QUIC flow-control limitation that was preventing large POST requests
>from working was addressed, so with this last limitation removed, the
>stack is expected to be fully operational. In addition, the HTTP/3
>decoder now has better latency as it doesn't need to wait for a full
>data frame anymore before starting to decode and forward it.
>
> - a new global setting "cluster-secret" was added. For now it's only used
>by QUIC for cluster-wide crypto such as retries so that a connection
>retry can be validated by any node. It will likely be used for more QUIC
>stuff, and it makes sense to use it for anything else that is
> cluster-wide
>in the future so the option was named without "quic" in its name.
>
> - New option "http-restrict-req-hdr-names" was added at the proxy level.
>It can be used to inspect HTTP header names and decide what to do with
>those having any character other than alphanumerical or dash ("-"),
>either delete the header or reject the request. The purpose is to help
>protect application servers that map dash to underscore due to CGI
>inheritance, or worse, which crash when passed such characters. The
>option is automatically set to the delete mode in backends having
>FastCGI configured. This will eventually be backported, because we got
>reports of such broken application servers deployed in field where site
>owners count on haproxy to work around this problem.
>
> - some configuration issues related to QUIC remained, by which it was
>possible to combine incompatible values of "proto" and sockets, such
>as a QUIC bind with a "proto h2" or no "proto", or "proto quic" on a
>TCP line, or a QUIC address used in peers, or "quic" without "ssl" etc.
>And such combinations were problematic at runtime because the QUIC mux
>and transport cannot be split apart, so each being used with the wrong
>other part caused immediate crashes. This is what made "proto quic"
>mandatory for QUIC bind lines. This was finally sorted out so that
>incompatible
[ANNOUNCE] haproxy-2.6-dev11
Hi,
HAProxy 2.6-dev11 was released on 2022/05/20. It added 106 new commits
after version 2.6-dev10.
Yes, there were still too many changes for a final version, that's often
like this when getting close to a release. And I couldn't finish the
renaming of the confusing stuff in the conn_stream layer, for which I'll
rely on Christopher's help next week. I now understand the trouble some
developers face when creating an applet and why the only practical
solution is to copy-paste existing stuff, because even some of the
existing functions' comments are ambiguous if you stumble on them with
the wrong idea of what they do, and I absolutely want to address this
for the release, or it will further complicate development in new
versions, or maintenance of 2.6 if we rename later.
Most of the changes are of minor importance, or bug fixes though, but
some are particularly interesting:
- on the SSL front, a few global settings were added to configure the
ssl-providers that come with OpenSSL 3 to replace the engines. At this
point it's not totally clear to me how this will evolve, but since
these are just global settings that are very likely to become necessary
mid-term, it's better if they're readily available.
- QUIC now provides a number of counters of retries, errors etc, and
finally supports the Retry mechanism, which is the QUIC equivalent of
the TCP SYN cookies. These are used to validate a client's connection
request and make sure it's not a spoofed packet. They can be forced, or
will be automatically enabled when a configurable number of incoming
connections are not yet confirmed. This is done via the global
"tune.quic.retry-threshold" parameter. BTW I'm just seeing that it's
not documented yet; Fred, please do not forget to update it!
- outgoing applets now support delayed initialization. I know it's a bit
late for merging this but it addresses a long-existing problem with the
peers and that could possibly be further emphasized with the http client.
The problem was that outgoing applets were only created on the thread
that required them, and for peers it was created during config parsing,
thus all outgoing applets were on thread 1, possibly eating a lot of
CPU on this thread. That's the issue that Maciej Zdeb reported a month
ago. Maciej tried to address this but there was a chicken-and-egg issue
that made it impossible to create the applets on another thread. Now
that they can be initialized later, it's possible to schedule them on
any thread, and Maciej's patches could be integrated as well, so the
peers will no longer aggregate mostly on one thread.
- a QUIC flow-control limitation that was preventing large POST requests
from working was addressed, so with this last limitation removed, the
stack is expected to be fully operational. In addition, the HTTP/3
decoder now has better latency as it doesn't need to wait for a full
data frame anymore before starting to decode and forward it.
- a new global setting "cluster-secret" was added. For now it's only used
by QUIC for cluster-wide crypto such as retries so that a connection
retry can be validated by any node. It will likely be used for more QUIC
stuff, and it makes sense to use it for anything else that is cluster-wide
in the future so the option was named without "quic" in its name.
- New option "http-restrict-req-hdr-names" was added at the proxy level.
It can be used to inspect HTTP header names and decide what to do with
those having any character other than alphanumerical or dash ("-"),
either delete the header or reject the request. The purpose is to help
protect application servers that map dash to underscore due to CGI
inheritance, or worse, which crash when passed such characters. The
option is automatically set to the delete mode in backends having
FastCGI configured. This will eventually be backported, because we got
reports of such broken application servers deployed in field where site
owners count on haproxy to work around this problem.
- some configuration issues related to QUIC remained, by which it was
possible to combine incompatible values of "proto" and sockets, such
as a QUIC bind with a "proto h2" or no "proto", or "proto quic" on a
TCP line, or a QUIC address used in peers, or "quic" without "ssl" etc.
And such combinations were problematic at runtime because the QUIC mux
and transport cannot be split apart, so each being used with the wrong
other part caused immediate crashes. This is what made "proto quic"
mandatory for QUIC bind lines. This was finally sorted out so that
incompatible combinations are now rejected at parsing time, "ssl" is
implied but warns that it's missing, and that "proto quic" is no more
necessary, as implied by the presence of "quic" in the address which
implies the use of QUIC connections.
- some build fixes on FreeBSD 13.1 and Solaris
- the
