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
