DOC: Spelling fixes

[wt: this contains spelling fixes for both doc and code comments,
 should be backported, ignoring the parts which don't apply]

CONTRIBUTING

@@ -103,7 +103,7 @@ do not think about them anymore after a few patches.
    licenses and to contribute your changes under the same licenses. If you want
    to create new files, they will be under the main license, or any license of
    your choice that you have verified to be compatible with the main license,
-   and that will be explicitly mentionned in the affected files. The project's
+   and that will be explicitly mentioned in the affected files. The project's
    maintainers are free to reject contributions proposing license changes they
    feel are not appropriate or could cause future trouble.
 
@@ -301,7 +301,7 @@ do not think about them anymore after a few patches.
    mangle the context in an invisible way. Such patches with trailing spaces at
    end of lines will be rejected.
 
-10) Please cut your work in series of patches that can be independantly reviewed
+10) Please cut your work in series of patches that can be independently reviewed
     and merged. Each patch must do something on its own that you can explain to
     someone without being ashamed of what you did. For example, you must not say
     "This is the patch that implements SSL, it was tricky". There's clearly
@@ -327,14 +327,14 @@ do not think about them anymore after a few patches.
     required to use Git, it is strongly recommended because it helps you do the
     cleanest job with the least effort. Patches always have the format of an
     e-mail made of a subject, a description and the actual patch. If you're
-    sending a patch as an e-mail formated this way, it can quickly be applied
+    sending a patch as an e-mail formatted this way, it can quickly be applied
     with limited effort so that's acceptable. But in any case, it is important
     that there is a clean description of what the patch does, the motivation for
     what it does, why it's the best way to do it, its impacts, and what it does
     not yet cover. Also, in HAProxy, like many projects which take a great care
     of maintaining stable branches, patches are reviewed later so that some of
     them can be backported to stable releases. While reviewing hundreds of
-    patches can seem cumbersome, with a proper formating of the subject line it
+    patches can seem cumbersome, with a proper formatting of the subject line it
     actually becomes very easy. For example, here's how one can find patches
     that need to be reviewed for backports (bugs and doc) between since commit
     ID 827752e :
@@ -354,22 +354,22 @@ do not think about them anymore after a few patches.
         386a127 DOC: match several lua configuration option names to those impl
         0f4eadd BUG/MEDIUM: counters: ensure that src_{inc,clr}_gpc0 creates a
 
-    It is made possible by the fact that subject lines are properly formated and
+    It is made possible by the fact that subject lines are properly formatted and
     always respect the same principle : one part indicating the nature and
     severity of the patch, another one to indicate which subsystem is affected,
-    and the last one is a succint description of the change, with the important
+    and the last one is a succinct description of the change, with the important
     part at the beginning so that it's obvious what it does even when lines are
     truncated like above. The whole stable maintenance process relies on this.
     For this reason, it is mandatory to respect some easy rules regarding the
     way the subject is built. Please see the section below for more information
-    regarding this formating.
+    regarding this formatting.
 
 12) When submitting changes, please always CC the mailing list address so that
     everyone gets a chance to spot any issue in your code. It will also serve
     as an advertisement for your work, you'll get more testers quicker and
     you'll feel better knowing that people really use your work. It is also
-    important to CC any author mentionned in the file you change, or a subsystem
+    important to CC any author mentioned in the file you change, or a subsystem
-    maintainers whose address is mentionned in a MAINTAINERS file. Not everyone
+    maintainers whose address is mentioned in a MAINTAINERS file. Not everyone
     reads the list on a daily basis so it's very easy to miss some changes.
     Don't consider it as a failure when a reviewer tells you you have to modify
     your patch, actually it's a success because now you know what is missing for
@@ -407,7 +407,7 @@ patch types include :
              identifier was assigned before you publish the fix, you can mention
              it in the commit message, it will help distro maintainers.
 
-  - CLEANUP  code cleanup, silence of warnings, etc... theorically no impact.
+  - CLEANUP  code cleanup, silence of warnings, etc... theoretically no impact.
              These patches will rarely be seen in stable branches, though they
              may appear when they remove some annoyance or when they make
              backporting easier. By nature, a cleanup is always of minor
@@ -621,7 +621,7 @@ Then reorder/merge/edit your patches :
    $ git rebase -i master
 
 When you think you're ready, reread your whole patchset to ensure there is no
-formating or style issue :
+formatting or style issue :
 
    $ git show master..
 

doc/configuration.txt

@@ -1323,7 +1323,7 @@ tune.idletimer <timeout>
 
 tune.lua.forced-yield <number>
   This directive forces the Lua engine to execute a yield each <number> of
-  instructions executed. This permits interruptng a long script and allows the
+  instructions executed. This permits interrupting a long script and allows the
   HAProxy scheduler to process other tasks like accepting connections or
   forwarding traffic. The default value is 10000 instructions. If HAProxy often
   executes some Lua code but more reactivity is required, this value can be
@@ -3294,10 +3294,10 @@ filter <name> [param*]
     <name>     is the name of the filter. Officially supported filters are
                referenced in section 9.
 
-    <param*>   is a list of parameters accpeted by the filter <name>. The
+    <param*>   is a list of parameters accepted by the filter <name>. The
                parsing of these parameters are the responsibility of the
-               filter. Please refer to the documention of the corresponding
+               filter. Please refer to the documentation of the corresponding
-               filter (section 9) from all details on the supported parameters.
+               filter (section 9) for all details on the supported parameters.
 
   Multiple occurrences of the filter line can be used for the same proxy. The
   same filter can be referenced many times if needed.
@@ -5377,7 +5377,7 @@ no option http-buffer-request
   frontend or backend forces the HTTP processing to wait until either the whole
   body is received, or the request buffer is full, or the first chunk is
   complete in case of chunked encoding. It can have undesired side effects with
-  some applications abusing HTTP by expecting unbufferred transmissions between
+  some applications abusing HTTP by expecting unbuffered transmissions between
   the frontend and the backend, so this should definitely not be used by
   default.
 
@@ -10482,10 +10482,10 @@ strict-sni
   See the "crt" option for more information.
 
 tcp-ut <delay>
-  Sets the TCP User Timeout for all incoming connections instanciated from this
+  Sets the TCP User Timeout for all incoming connections instantiated from this
   listening socket. This option is available on Linux since version 2.6.37. It
   allows haproxy to configure a timeout for sockets which contain data not
-  receiving an acknoledgement for the configured delay. This is especially
+  receiving an acknowledgement for the configured delay. This is especially
   useful on long-lived connections experiencing long idle periods such as
   remote terminals or database connection pools, where the client and server
   timeouts must remain high to allow a long period of idle, but where it is
@@ -11122,7 +11122,7 @@ resolve-prefer <family>
 resolve-net <network>[,<network[,...]]
   This options prioritize th choice of an ip address matching a network. This is
   useful with clouds to prefer a local ip. In some cases, a cloud high
-  avalailibility service can be announced with many ip addresses on many
+  availability service can be announced with many ip addresses on many
   differents datacenters. The latency between datacenter is not negligible, so
   this patch permitsto prefers a local datacenter. If none address matchs the
   configured network, another address is selected.
@@ -11272,7 +11272,7 @@ tcp-ut <delay>
   Sets the TCP User Timeout for all outgoing connections to this server. This
   option is available on Linux since version 2.6.37. It allows haproxy to
   configure a timeout for sockets which contain data not receiving an
-  acknoledgement for the configured delay. This is especially useful on
+  acknowledgement for the configured delay. This is especially useful on
   long-lived connections experiencing long idle periods such as remote
   terminals or database connection pools, where the client and server timeouts
   must remain high to allow a long period of idle, but where it is important to
@@ -12197,7 +12197,7 @@ bool
 bytes(<offset>[,<length>])
   Extracts some bytes from an input binary sample. The result is a binary
   sample starting at an offset (in bytes) of the original sample and
-  optionnaly truncated at the given length.
+  optionally truncated at the given length.
 
 cpl
   Takes the input value of type signed integer, applies a ones-complement
@@ -12398,7 +12398,7 @@ map_<match_type>_<output_type>(<map_file>[,<default_value>])
   strings are stored in trees, so the first of the finest match will be used.
   Other keys are stored in lists, so the first matching occurrence will be used.
 
-  The following array contains the list of all map functions avalaible sorted by
+  The following array contains the list of all map functions available sorted by
   input type, match type and output type.
 
   input type | match method | output type str | output type int | output type ip
@@ -14386,7 +14386,7 @@ query : string
   question mark. If no question mark is present, this fetch returns nothing. If
   a question mark is present but nothing follows, it returns an empty string.
   This means it's possible to easily know whether a query string is present
-  using the "found" matching method. This fetch is the completemnt of "path"
+  using the "found" matching method. This fetch is the complement of "path"
   which stops before the question mark.
 
 req.hdr_names([<delim>]) : string
@@ -16225,7 +16225,7 @@ also requires dedicated backends, defined in HAProxy configuration.
 SPOE communicates with external components using an in-house binary protocol,
 the Stream Processing Offload Protocol (SPOP).
 
-For all information about the SPOE configuation and the SPOP specification, see
+For all information about the SPOE configuration and the SPOP specification, see
 "doc/SPOE.txt".
 
 Important note:

doc/haproxy.1

@@ -35,7 +35,7 @@ instances without risking the system's stability.
 .TP
 \fB\-f <configuration file|dir>\fP
 Specify configuration file or directory path. If the argument is a directory
-the files (and only files) it containes are added in lexical order (using
+the files (and only files) it contains are added in lexical order (using
 LC_COLLATE=C) ; only non hidden files with ".cfg" extension are added.
 
 .TP

src/backend.c

@@ -1019,7 +1019,7 @@ static void assign_tproxy_address(struct stream *s)
  *  - SF_ERR_PRXCOND if the connection has been limited by the proxy (maxconn)
  *  - SF_ERR_RESOURCE if a system resource is lacking (eg: fd limits, ports, ...)
  *  - SF_ERR_INTERNAL for any other purely internal errors
- * Additionnally, in the case of SF_ERR_RESOURCE, an emergency log will be emitted.
+ * Additionally, in the case of SF_ERR_RESOURCE, an emergency log will be emitted.
  * The server-facing stream interface is expected to hold a pre-allocated connection
  * in s->si[1].conn.
  */

src/checks.c

@@ -1459,7 +1459,7 @@ static struct task *server_warmup(struct task *t)
  *  - SF_ERR_RESOURCE if a system resource is lacking (eg: fd limits, ports, ...)
  *  - SF_ERR_INTERNAL for any other purely internal errors
  *  - SF_ERR_CHK_PORT if no port could be found to run a health check on an AF_INET* socket
- * Additionnally, in the case of SF_ERR_RESOURCE, an emergency log will be emitted.
+ * Additionally, in the case of SF_ERR_RESOURCE, an emergency log will be emitted.
  * Note that we try to prevent the network stack from sending the ACK during the
  * connect() when a pure TCP check is used (without PROXY protocol).
  */
@@ -1841,7 +1841,7 @@ err:
  *  - SF_ERR_PRXCOND if the connection has been limited by the proxy (maxconn)
  *  - SF_ERR_RESOURCE if a system resource is lacking (eg: fd limits, ports, ...)
  *  - SF_ERR_INTERNAL for any other purely internal errors
- * Additionnally, in the case of SF_ERR_RESOURCE, an emergency log will be emitted.
+ * Additionally, in the case of SF_ERR_RESOURCE, an emergency log will be emitted.
  *
  * Blocks and then unblocks SIGCHLD
  */
@@ -2767,7 +2767,7 @@ static void tcpcheck_main(struct connection *conn)
 			 *  - SF_ERR_PRXCOND if the connection has been limited by the proxy (maxconn)
 			 *  - SF_ERR_RESOURCE if a system resource is lacking (eg: fd limits, ports, ...)
 			 *  - SF_ERR_INTERNAL for any other purely internal errors
-			 * Additionnally, in the case of SF_ERR_RESOURCE, an emergency log will be emitted.
+			 * Additionally, in the case of SF_ERR_RESOURCE, an emergency log will be emitted.
 			 * Note that we try to prevent the network stack from sending the ACK during the
 			 * connect() when a pure TCP check is used (without PROXY protocol).
 			 */

src/proto_tcp.c

@@ -267,7 +267,7 @@ static int create_server_socket(struct connection *conn)
  *  - SF_ERR_PRXCOND if the connection has been limited by the proxy (maxconn)
  *  - SF_ERR_RESOURCE if a system resource is lacking (eg: fd limits, ports, ...)
  *  - SF_ERR_INTERNAL for any other purely internal errors
- * Additionnally, in the case of SF_ERR_RESOURCE, an emergency log will be emitted.
+ * Additionally, in the case of SF_ERR_RESOURCE, an emergency log will be emitted.
  *
  * The connection's fd is inserted only when SF_ERR_NONE is returned, otherwise
  * it's invalid and the caller has nothing to do.

src/proto_uxst.c

@@ -407,7 +407,7 @@ int uxst_pause_listener(struct listener *l)
  *  - SF_ERR_PRXCOND if the connection has been limited by the proxy (maxconn)
  *  - SF_ERR_RESOURCE if a system resource is lacking (eg: fd limits, ports, ...)
  *  - SF_ERR_INTERNAL for any other purely internal errors
- * Additionnally, in the case of SF_ERR_RESOURCE, an emergency log will be emitted.
+ * Additionally, in the case of SF_ERR_RESOURCE, an emergency log will be emitted.
  *
  * The connection's fd is inserted only when SF_ERR_NONE is returned, otherwise
  * it's invalid and the caller has nothing to do.