DOC: fix a few spelling mistakes in the docs
These were reported by the CI's spell checker: https://github.com/haproxy/haproxy/actions/runs/2411893527 A few need to be ignored ("ressources" and "trafic" being part of a URL).
This commit is contained in:
parent
453d60be17
commit
55b9689bbe
|
@ -196,7 +196,7 @@ carry the stream identifier.
|
|||
|
||||
|
||||
HTTP/3 is implemented over QUIC, itself implemented over UDP. QUIC solves the
|
||||
head of line blocking at transport level by means of independantly treated
|
||||
head of line blocking at transport level by means of independently treated
|
||||
streams. Indeed, when experiencing loss, an impacted stream does not affect the
|
||||
other streams.
|
||||
|
||||
|
@ -2091,16 +2091,19 @@ ssl-provider <name>
|
|||
might be used by HAProxy. Multiple 'ssl-provider' options can be specified in
|
||||
a configuration file. The providers will be loaded in their order of
|
||||
appearance.
|
||||
Please note that loading a provider explicitely prevents OpenSSL from loading
|
||||
|
||||
Please note that loading a provider explicitly prevents OpenSSL from loading
|
||||
the 'default' provider automatically. OpenSSL also allows to define the
|
||||
providers that should be loaded directly in its configuration file
|
||||
(openssl.cnf for instance) so it is not necessary to use this 'ssl-provider'
|
||||
option to load providers. The "show ssl providers" CLI command can be used to
|
||||
show all the providers that were successfully loaded.
|
||||
|
||||
The default search path of OpenSSL provider can be found in the output of the
|
||||
"openssl version -a" command. If the provider is in another directory, you
|
||||
can set the OPENSSL_MODULES environment variable, which takes the directory
|
||||
where your provider can be found.
|
||||
|
||||
See also "ssl-propquery" and "ssl-provider-path".
|
||||
|
||||
ssl-provider-path <path>
|
||||
|
@ -2981,8 +2984,8 @@ tune.quic.retry-threshold <number>
|
|||
connection is a connection whose handshake has not already successfully
|
||||
completed or failed. To be functional this setting needs a cluster secret to
|
||||
be set, if not it will be silently ignored (see "cluster-secret" setting).
|
||||
This setting will be also silenty ignored if the use of QUIC Retry was forced
|
||||
(see "quic-force-retry").
|
||||
This setting will be also silently ignored if the use of QUIC Retry was
|
||||
forced (see "quic-force-retry").
|
||||
|
||||
The default value is 100.
|
||||
|
||||
|
@ -14781,7 +14784,7 @@ check
|
|||
connection headers, "check-ssl" to use SSL/TLS.
|
||||
|
||||
Note that the implicit configuration of ssl and PROXY protocol is not
|
||||
performed for dynamic servers. In this case, it is required to explicitely
|
||||
performed for dynamic servers. In this case, it is required to explicitly
|
||||
use "check-ssl" and "check-send-proxy" when wanted, even if the check port is
|
||||
not overridden.
|
||||
|
||||
|
|
|
@ -228,7 +228,7 @@ FD Notes
|
|||
of running_mask to gauge a change or temporarily lock it during a
|
||||
removal could make sense.
|
||||
|
||||
- running should be conditionned by thread. Polled not (since deferred
|
||||
- running should be conditioned by thread. Polled not (since deferred
|
||||
or migrated). In this case testing thread_mask can be enough most of
|
||||
the time, but this requires synchronization that will have to be
|
||||
extended to tgid.. But migration seems a different beast that we shouldn't
|
||||
|
@ -273,7 +273,7 @@ mux_takeover(): | fd_set_running():
|
|||
return fail; | new = {tid_bit, tid_bit};
|
||||
... |
|
||||
fd_takeover(): | do {
|
||||
atomic_or(runnning, tid_bit); | if (!(old.thread & tid_bit))
|
||||
atomic_or(running, tid_bit); | if (!(old.thread & tid_bit))
|
||||
old = {running, thread}; | return -1;
|
||||
new = {tid_bit, tid_bit}; | new = { running | tid_bit, old.thread }
|
||||
if (owner != expected) { | } while (!dwcas({running, thread}, &old, &new));
|
||||
|
|
|
@ -219,7 +219,7 @@ list of options is :
|
|||
using "-dKall", otherwise a selection of those shown in the help can be
|
||||
specified as a comma-delimited list. The output format will vary depending
|
||||
on what class of keywords is being dumped (e.g. "cfg" will show the known
|
||||
configuration keywords in a format ressembling the config file format while
|
||||
configuration keywords in a format resembling the config file format while
|
||||
"smp" will show sample fetch functions prefixed with a compatibility matrix
|
||||
with each rule set). These may rarely be used as-is by humans but can be of
|
||||
great help for external tools that try to detect the appearance of new
|
||||
|
|
Loading…
Reference in New Issue