DOC: fix some spelling issues over multiple files
This is from the output of codespell and may be backported.
This commit is contained in:
parent
5a982a7165
commit
cdbcca9995
2
BRANCHES
2
BRANCHES
|
@ -134,7 +134,7 @@ to make a safe guess about what to pick.
|
|||
Branches up to 1.8 are all designated as "long-term supported" ("LTS" for
|
||||
short), which means that they are maintained for several years after the
|
||||
release. These branches were emitted at a pace of one per year since 1.5 in
|
||||
2014. As of 2019, 1.5 is still supported and widely used, eventhough it very
|
||||
2014. As of 2019, 1.5 is still supported and widely used, even though it very
|
||||
rarely receives updates. After a few years these LTS branches enter a
|
||||
"critical fixes only" status, which means that they will rarely receive a fix
|
||||
but if that a critital issue affects them, a release will be made, with or
|
||||
|
|
|
@ -154,7 +154,7 @@ features are disabled. Similarly, when modifying the SSL stack, please always
|
|||
ensure that supported OpenSSL versions continue to build and to work, especially
|
||||
if you modify support for alternate libraries. Clean support for the legacy
|
||||
OpenSSL libraries is mandatory, support for its derivatives is a bonus and may
|
||||
occasionally break eventhough a great care is taken. In other words, if you
|
||||
occasionally break even though a great care is taken. In other words, if you
|
||||
provide a patch for OpenSSL you don't need to test its derivatives, but if you
|
||||
provide a patch for a derivative you also need to test with OpenSSL.
|
||||
|
||||
|
|
2
INSTALL
2
INSTALL
|
@ -528,7 +528,7 @@ because of strange symbols or section mismatches, simply remove -g from
|
|||
DEBUG_CFLAGS.
|
||||
|
||||
Building on AIX 7.2 works fine using the "aix72-gcc" TARGET. It adds two
|
||||
special CFLAGS to prevent the loading of AIXs xmem.h and var.h. This is done
|
||||
special CFLAGS to prevent the loading of AIX's xmem.h and var.h. This is done
|
||||
by defining the corresponding include-guards _H_XMEM and _H_VAR. Without
|
||||
excluding those header-files the build fails because of redefinition errors.
|
||||
Furthermore, the atomic library is added to the LDFLAGS to allow for
|
||||
|
|
|
@ -406,7 +406,7 @@ HAProxy's configuration process involves 3 major sources of parameters :
|
|||
|
||||
- the arguments from the command-line, which always take precedence
|
||||
- the configuration file(s), whose format is described here
|
||||
- the running process' environment, in case some environment variables are
|
||||
- the running process's environment, in case some environment variables are
|
||||
explicitly referenced
|
||||
|
||||
The configuration file follows a fairly simple hierarchical format which obey
|
||||
|
@ -1083,7 +1083,7 @@ external-check
|
|||
"insecure-setuid-wanted".
|
||||
|
||||
gid <number>
|
||||
Changes the process' group ID to <number>. It is recommended that the group
|
||||
Changes the process's group ID to <number>. It is recommended that the group
|
||||
ID is dedicated to HAProxy or to a small set of similar daemons. HAProxy must
|
||||
be started with a user belonging to this group, or with superuser privileges.
|
||||
Note that if haproxy is started from a user having supplementary groups, it
|
||||
|
@ -1756,7 +1756,7 @@ stats maxconn <connections>
|
|||
possible to change this value with "stats maxconn".
|
||||
|
||||
uid <number>
|
||||
Changes the process' user ID to <number>. It is recommended that the user ID
|
||||
Changes the process's user ID to <number>. It is recommended that the user ID
|
||||
is dedicated to HAProxy or to a small set of similar daemons. HAProxy must
|
||||
be started with superuser privileges in order to be able to switch to another
|
||||
one. See also "gid" and "user".
|
||||
|
@ -14410,7 +14410,7 @@ weight <weight>
|
|||
|
||||
HAProxy allows using a host name on the server line to retrieve its IP address
|
||||
using name servers. By default, HAProxy resolves the name when parsing the
|
||||
configuration file, at startup and cache the result for the process' life.
|
||||
configuration file, at startup and cache the result for the process's life.
|
||||
This is not sufficient in some cases, such as in Amazon where a server's IP
|
||||
can change after a reboot or an ELB Virtual IP can change based on current
|
||||
workload.
|
||||
|
@ -20369,7 +20369,7 @@ easier finding and understanding.
|
|||
external attacks.
|
||||
|
||||
PC The proxy refused to establish a connection to the server because the
|
||||
process' socket limit has been reached while attempting to connect.
|
||||
process's socket limit has been reached while attempting to connect.
|
||||
The global "maxconn" parameter may be increased in the configuration
|
||||
so that it does not happen anymore. This status is very rare and
|
||||
might happen when the global "ulimit-n" parameter is forced by hand.
|
||||
|
|
|
@ -25,7 +25,7 @@ reports no more value. This makes sense for instance when checking IP addresses
|
|||
found in HTTP headers, which can appear multiple times. The acl_test is kept
|
||||
intact between calls and even holds a context so that the fetch function knows
|
||||
where to start from for subsequent calls. The match function may also use the
|
||||
context eventhough it was not designed for that purpose.
|
||||
context even though it was not designed for that purpose.
|
||||
|
||||
An ACL is defined only by its name and can be a series of ACL expressions. The
|
||||
ACL is deemed true when any of its expressions is true. They are evaluated in
|
||||
|
@ -35,7 +35,7 @@ So in summary :
|
|||
|
||||
- an ACL is a series of tests to perform on a stream, any of which is enough
|
||||
to validate the result.
|
||||
|
||||
|
||||
- each test is defined by an expression associating a keyword and a series of
|
||||
patterns.
|
||||
|
||||
|
@ -59,7 +59,7 @@ a suite. A term simply is a pointer to an ACL.
|
|||
|
||||
We could then represent a rule by the following BNF :
|
||||
|
||||
rule = if-cond
|
||||
rule = if-cond
|
||||
| unless-cond
|
||||
|
||||
if-cond (struct acl_cond with ->pol = ACL_COND_IF)
|
||||
|
|
|
@ -9,7 +9,7 @@ used during data transformation such as compression, header insertion or
|
|||
defragmentation, and are used to carry intermediary representations between the
|
||||
various internal layers. They support wrapping at the end, and they carry their
|
||||
own size information so that in theory it would be possible to use different
|
||||
buffer sizes in parallel eventhough this is not currently implemented.
|
||||
buffer sizes in parallel even though this is not currently implemented.
|
||||
|
||||
The format of this structure has evolved over time, to reach a point where it
|
||||
is convenient and versatile enough to have permitted to make several internal
|
||||
|
|
|
@ -113,8 +113,8 @@ payload.
|
|||
|
||||
Because the payloads part may wrap, there are 2 usable free spaces:
|
||||
|
||||
- The free space in front of the blocks part. This one is used iff the other
|
||||
one was not used yet.
|
||||
- The free space in front of the blocks part. This one is used if and only if
|
||||
the other one was not used yet.
|
||||
|
||||
- The free space at the beginning of the message. Once this one is used, the
|
||||
other one is never used again, until a message defragmentation.
|
||||
|
|
|
@ -1276,7 +1276,7 @@ HAProxy protects itself against it.
|
|||
|
||||
On Linux, a new starting process may communicate with the previous one to reuse
|
||||
its listening file descriptors so that the listening sockets are never
|
||||
interrupted during the process' replacement.
|
||||
interrupted during the process's replacement.
|
||||
|
||||
|
||||
3.4.3. Advanced features : Scripting
|
||||
|
|
|
@ -1986,7 +1986,7 @@ show activity
|
|||
of reports of abnormal behaviours. A typical example would be a properly
|
||||
running process never sleeping and eating 100% of the CPU. The output fields
|
||||
will be made of one line per metric, and per-thread counters on the same
|
||||
line. These counters are 32-bit and will wrap during the process' life, which
|
||||
line. These counters are 32-bit and will wrap during the process's life, which
|
||||
is not a problem since calls to this command will typically be performed
|
||||
twice. The fields are purposely not documented so that their exact meaning is
|
||||
verified in the code where the counters are fed. These values are also reset
|
||||
|
|
Loading…
Reference in New Issue