DOC: assorted typo fixes in the documentation

This is the third round of cleanups in various docs

BRANCHES

@@ -191,7 +191,7 @@ Thus the release cycle from 1.8 to 2.2 should look like this:
          `---+---+---+-----+-------+-----------+---------------+------> 1.8 LTS
 
 In short the non-LTS odd releases can be seen as technological previews of the
-next feature release, and will be terminated much ealier. The plan is to barely
+next feature release, and will be terminated much earlier. The plan is to barely
 let them overlap with the next non-LTS release, allowing advanced users to
 always have the choice between the last two major releases.
 

doc/design-thoughts/entities-v2.txt

@@ -119,7 +119,7 @@ Identified handshake handlers for incoming connections :
   - HH_ACCEPT_PROXY (waits for PROXY line and parses it)
   - HH_TCP_RULES (processes TCP rules)
   - HH_SSL_HS (starts SSL handshake)
-  - HH_ACCEPT_SESSION (instanciates a session)
+  - HH_ACCEPT_SESSION (instantiates a session)
 
 Identified handshake handlers for outgoing connections :
   - HH_SEND_PROXY (tries to build and send the PROXY line)

doc/design-thoughts/http2.txt

@@ -97,7 +97,7 @@
   before the connection timeout so that an unused connection is verified before
   being killed. Abnormal requests must be dealt with using RST_STREAM.
 
-- ALPN : ALPN must be observed onthe client side, and transmitted to the server
+- ALPN : ALPN must be observed on the client side, and transmitted to the server
   side.
 
 - proxy protocol : proxy protocol makes little to no sense in a multiplexed
@@ -134,7 +134,7 @@
   to H2 behind. This can cause some trouble when passing H2 requests to H1
   proxies, because there's no way to know if the request should contain scheme
   and authority in H1 or not based on the H2 request. Thus a "proxy" option
-  will have to be explicitly mentionned on HTTP/1 server lines. One of the
+  will have to be explicitly mentioned on HTTP/1 server lines. One of the
   problem that it creates is that it's not longer possible to pass H/1 requests
   to H/1 proxies without an explicit configuration. Maybe a table of the
   various combinations is needed.

doc/internals/buffer-api.txt

@@ -630,7 +630,7 @@ but fail.
                    <------------------> <---------->
                             o                i
 
-There is this correspondance between old and new fields (some will involve a
+There is this correspondence between old and new fields (some will involve a
 knowledge of a channel when the output byte count is required) :
 
      Old    | New

doc/internals/entities-v2.txt

@@ -116,7 +116,7 @@ Identified handshake handlers for incoming connections :
   - HH_ACCEPT_PROXY (waits for PROXY line and parses it)
   - HH_TCP_RULES (processes TCP rules)
   - HH_SSL_HS (starts SSL handshake)
-  - HH_ACCEPT_SESSION (instanciates a session)
+  - HH_ACCEPT_SESSION (instantiates a session)
 
 Identified handshake handlers for outgoing connections :
   - HH_SEND_PROXY (tries to build and send the PROXY line)

doc/internals/entities.txt

@@ -9,7 +9,7 @@ Listener
 
 A listener is the entity which is part of a frontend and which accepts
 connections. There are as many listeners as there are ip:port couples.
-There is at least one listener instanciated for each "bind" entry, and
+There is at least one listener instantiated for each "bind" entry, and
 port ranges will lead to as many listeners as there are ports in the
 range. A listener just has a listening file descriptor ready to accept
 incoming connections and to dispatch them to upper layers.
@@ -18,8 +18,8 @@ incoming connections and to dispatch them to upper layers.
 Initiator
 ---------
 
-An initiator is instanciated for each incoming connection on a listener. It may
+An initiator is instantiated for each incoming connection on a listener. It may
-also be instanciated by a task pretending to be a client. An initiator calls
+also be instantiated by a task pretending to be a client. An initiator calls
 the next stage's accept() callback to present it with the parameters of the
 incoming connection.
 
@@ -39,7 +39,7 @@ side and other ones on the connector side. If additional buffers are needed for
 such transforms, those buffers cannot replace the session's buffers, but they
 may complete them.
 
-A session only needs to be instanciated when forwarding of data is required
+A session only needs to be instantiated when forwarding of data is required
 between two sides. Accepting and filtering on layer 4 information only does not
 require a session.
 
@@ -76,7 +76,7 @@ side of diagrams.
 Connection
 ----------
 
-A connection is the entity instanciated by a connector. It may be composed of
+A connection is the entity instantiated by a connector. It may be composed of
 multiple stages linked together. Generally it is the part of the stream
 interface holding a file descriptor, but it can also be a processing block or a
 transformation block terminated by a connection. A connection presents a
@@ -86,11 +86,11 @@ server-side interface.
 2) Sequencing
 -------------
 
-Upon startup, listeners are instanciated by the configuration. When an incoming
+Upon startup, listeners are instantiated by the configuration. When an incoming
 connection reaches a listening file descriptor, its read() callback calls the
-corresponding listener's accept() function which instanciates an initiator and
+corresponding listener's accept() function which instantiates an initiator and
 in turn recursively calls upper layers' accept() callbacks until
-accept_session() is called. accept_session() instanciates a new session which
+accept_session() is called. accept_session() instantiates a new session which
 starts protocol analysis via process_session(). When all protocol analysis is
 done, process_session() calls the connect() callback of the connector in order
 to get a connection.

doc/internals/filters.txt

@@ -84,7 +84,7 @@ filters are also chained, frontend ones called first. Even if the filters
 processing is serialized, each filter will bahave as it was alone (unless it was
 developed to be aware of other filters). For all that, some constraints are
 imposed to filters, especially when data exchanged between the client and the
-server are processed. We will dicuss again these contraints when we will tackle
+server are processed. We will dicuss again these constraints when we will tackle
 the subject of writing a filter.
 
 
@@ -93,7 +93,7 @@ the subject of writing a filter.
 ---------------------
 
 To use a filter, you must use the parameter 'filter' followed by the filter name
-and, optionnaly, its configuration in the desired listen, frontend or backend
+and, optionally, its configuration in the desired listen, frontend or backend
 section. For example:
 
     listen test
@@ -123,7 +123,7 @@ Multiple filter lines can be used in a proxy section to chain filters. Filters
 will be called in the declaration order.
 
 Some filters can support implicit declarartions in certain circumstances
-(without the filter line). This is not recommanded for new features but are
+(without the filter line). This is not recommended for new features but are
 useful for existing ones moved in a filter, for backward compatibility
 reasons. Implicit declarartions are supported when there is only one filter used
 on a proxy. When several filters are used, explicit declarartions are mandatory.
@@ -131,7 +131,7 @@ The HTTP compression filter is one of these filters. Alone, using 'compression'
 keywords is enough to use it. But when at least a second filter is used, a
 filter line must be added.
 
-    # filter line is optionnal
+    # filter line is optional
     listen t1
         bind *:80
         compression algo gzip
@@ -306,7 +306,7 @@ Filter instances attached to a stream are stored in the field
      *
      * 2D-Array fields are used to store info per channel. The first index
      * stands for the request channel, and the second one for the response
-     * channel.  Especially, <next> and <fwd> are offets representing amount of
+     * channel.  Especially, <next> and <fwd> are offsets representing amount of
      * data that the filter are, respectively, parsed and forwarded on a
      * channel. Filters can access these values using FLT_NXT and FLT_FWD
      * macros.
@@ -445,7 +445,7 @@ In the previous example, we expect to read a filter line as follows:
     filter my_filter name MY_NAME ...
 
 
-Optionnaly, by implementing the 'flt_ops.check' callback, you add a step to
+Optionally, by implementing the 'flt_ops.check' callback, you add a step to
 check the internal configuration of your filter after the parsing phase, when
 the HAProxy configuration is fully defined. For example:
 
@@ -492,7 +492,7 @@ Here is an example:
         return 0;
     }
 
-    /* Free ressources allocated by the trace filter. */
+    /* Free resources allocated by the trace filter. */
     static void
     my_filter_deinit(struct proxy *px, struct flt_conf *fconf)
     {
@@ -591,7 +591,7 @@ For example:
     }
 
 
-WARNING: Handling the streams creation and destuction is only possible for
+WARNING: Handling the streams creation and destruction is only possible for
          filters defined on proxies with the frontend capability.
 
 In addition, it is possible to handle creation and destruction of filter

doc/internals/htx-api.txt

@@ -9,7 +9,7 @@
 1. Background
 
 Historically, HAProxy stored HTTP messages in a raw fashion in buffers, keeping
-parsing information separatly in a "struct http_msg" owned by the stream. It was
+parsing information separately in a "struct http_msg" owned by the stream. It was
 optimized to the data transfer, but not so much for rewrites. It was also HTTP/1
 centered. While it was the only HTTP version supported, it was not a
 problem. But with the rise of HTTP/2, it starts to be hard to still use this
@@ -26,7 +26,7 @@ So, to address all these problems, we decided to replace the old raw
 representation by a version-agnostic and self-structured internal HTTP
 representation, the HTX. As an additional benefit, with this new representation,
 the message parsing and its processing are now separated, making all the HTTP
-analysis simplier and cleaner. The parsing of HTTP messages is now handled by
+analysis simpler and cleaner. The parsing of HTTP messages is now handled by
 the multiplexers (h1 or h2).
 
 
@@ -37,7 +37,7 @@ followed by a contiguous array with some parts of the message. These parts are
 called blocks. A block is composed of metadata (htx_blk) and an associated
 payload. Blocks' metadata are stored starting from the end of the array while
 their payload are stored at the beginning. Blocks' metadata are often simply
-called blocks. it is a misuse of language that's simplify explainations.
+called blocks. it is a misuse of language that's simplify explanations.
 
 Internally, this structure is "hidden" in a buffer. This way, there are few
 changes into intermediate layers (stream-interface and channels). They still
@@ -78,7 +78,7 @@ relatively to the beginning of the blocks array.
  at the position N       at the position 1      at the position 0
 
 
-In the HTX struture, 3 "special" positions are stored:
+In the HTX structure, 3 "special" positions are stored:
 
     - tail  : Position of the newest inserted block
     - head  : Position of the oldest inserted block
@@ -209,7 +209,7 @@ An HTX message is typically composed of following blocks, in this order :
 Only one HTTP request at a time can be stored in an HTX message. For HTTP
 response, it is more complicated. Only one "final" response can be stored in an
 HTX message. It is a response with status-code 101 or greater or equal to
-200. But it may be preceeded by several 1xx informational responses. Such
+200. But it may be preceded by several 1xx informational responses. Such
 responses are part of the same HTX message, so there is no end-of-message marker
 for them.
 

doc/internals/notes-layers.txt

@@ -110,7 +110,7 @@ It becomes visible that the mux will not always be welcome to decode incoming
 data because it will sometimes imply extra memory copies and/or usage for no
 benefit.
 
-Ideally, when when a stream is instanciated based on incoming data, these
+Ideally, when when a stream is instantiated based on incoming data, these
 incoming data should be passed and the upper layers called, but it should then
 be up these upper layers to peek more data in certain circumstances. Typically
 if the pending connection data are larger than what is expected to be passed
@@ -179,7 +179,7 @@ not implementing everything yet.
 Short term proposal : a channel has access to a buffer and a pipe. A non-empty
 buffer is either in structured message format OR raw stream format. Only the
 channel knows. However a structured buffer MAY contain raw data in a properly
-formated way (using the envelope defined by the structured message format).
+formatted way (using the envelope defined by the structured message format).
 
 By default, when a demux writes to a CS rxbuf, it will try to use the lowest
 possible level for what is being done (i.e. splice if possible, otherwise raw
@@ -269,7 +269,7 @@ Short term implementation :
 
   5) use the flags to enforce receipt of data only when necessary
 
-We should be able to end up with sequencial receipt in H2 modelling what is
+We should be able to end up with sequential receipt in H2 modelling what is
 needed for other protocols without interfering with the native H1 devs.
 
 

doc/lua-api/index.rst

@@ -311,7 +311,7 @@ Core class
 
   **context**: body, init, task, action, sample-fetch, converter
 
-  Returns HAProxy core informations. We can found information like the uptime,
+  Returns HAProxy core information. We can found information like the uptime,
   the pid, memory pool usage, tasks number, ...
 
   These information are also returned by the management socket via the command
@@ -792,7 +792,7 @@ Core class
   :returns: boolean, true if the network of the addresses match, else returns
     false.
 
-  Match two networks. For example "127.0.0.1/32" matchs "127.0.0.0/8". The order
+  Match two networks. For example "127.0.0.1/32" matches "127.0.0.0/8". The order
   of network is not important.
 
 .. js:function:: core.tokenize(str, separators [, noblank])
@@ -1137,7 +1137,7 @@ Concat class
 
   For each concatenation, Lua:
   * allocate memory for the result,
-  * catenate the two string copying the strings in the new memory bloc,
+  * catenate the two string copying the strings in the new memory block,
   * free the old memory block containing the string which is no longer used.
   This process does many memory move, allocation and free. In addition, the
   memory is not really freed, it is just mark mark as unused and wait for the
@@ -1176,7 +1176,7 @@ Concat class
   This function adds a string to the current concatenated string.
 
   :param class_concat concat: A :ref:`concat_class` which contains the currently
-    builded string.
+    built string.
   :param string string: A new string to concatenate to the current built
     string.
 
@@ -1185,7 +1185,7 @@ Concat class
   This function returns the concatenated string.
 
   :param class_concat concat: A :ref:`concat_class` which contains the currently
-    builded string.
+    built string.
   :returns: the concatenated string
 
 .. _fetches_class:
@@ -1214,7 +1214,7 @@ Fetches class
     connections established,
   * client information like ip source or destination,
   * deal with stick tables,
-  * Established SSL informations,
+  * Established SSL information,
   * HTTP information like headers or method.
 
 .. code-block:: lua
@@ -1278,7 +1278,7 @@ Channel class
   This function returns a string that contain the entire buffer. The data is
   not remove from the buffer and can be reprocessed later.
 
-  If the buffer cant receive more data, a 'nil' value is returned.
+  If the buffer can't receive more data, a 'nil' value is returned.
 
   :param class_channel channel: The manipulated Channel.
   :returns: a string containing all the available data or nil.
@@ -1288,7 +1288,7 @@ Channel class
   This function returns a string that contain the entire buffer. The data is
   consumed from the buffer.
 
-  If the buffer cant receive more data, a 'nil' value is returned.
+  If the buffer can't receive more data, a 'nil' value is returned.
 
   :param class_channel channel: The manipulated Channel.
   :returns: a string containing all the available data or nil.
@@ -1299,7 +1299,7 @@ Channel class
   data is consumed. If the data returned doesn't contains a final '\n' its
   assumed than its the last available data in the buffer.
 
-  If the buffer cant receive more data, a 'nil' value is returned.
+  If the buffer can't receive more data, a 'nil' value is returned.
 
   :param class_channel channel: The manipulated Channel.
   :returns: a string containing the available line or nil.
@@ -2230,7 +2230,7 @@ Map class
 .. js:attribute:: Map._int
 
   See the HAProxy configuration.txt file, chapter "Using ACLs and fetching
-  samples" ans subchapter "ACL basics" to understand this pattern matching
+  samples" and subchapter "ACL basics" to understand this pattern matching
   method.
 
   Note that :js:attr:`Map.int` is also available for compatibility.
@@ -2238,7 +2238,7 @@ Map class
 .. js:attribute:: Map._ip
 
   See the HAProxy configuration.txt file, chapter "Using ACLs and fetching
-  samples" ans subchapter "ACL basics" to understand this pattern matching
+  samples" and subchapter "ACL basics" to understand this pattern matching
   method.
 
   Note that :js:attr:`Map.ip` is also available for compatibility.
@@ -2246,7 +2246,7 @@ Map class
 .. js:attribute:: Map._str
 
   See the HAProxy configuration.txt file, chapter "Using ACLs and fetching
-  samples" ans subchapter "ACL basics" to understand this pattern matching
+  samples" and subchapter "ACL basics" to understand this pattern matching
   method.
 
   Note that :js:attr:`Map.str` is also available for compatibility.
@@ -2254,7 +2254,7 @@ Map class
 .. js:attribute:: Map._beg
 
   See the HAProxy configuration.txt file, chapter "Using ACLs and fetching
-  samples" ans subchapter "ACL basics" to understand this pattern matching
+  samples" and subchapter "ACL basics" to understand this pattern matching
   method.
 
   Note that :js:attr:`Map.beg` is also available for compatibility.
@@ -2262,7 +2262,7 @@ Map class
 .. js:attribute:: Map._sub
 
   See the HAProxy configuration.txt file, chapter "Using ACLs and fetching
-  samples" ans subchapter "ACL basics" to understand this pattern matching
+  samples" and subchapter "ACL basics" to understand this pattern matching
   method.
 
   Note that :js:attr:`Map.sub` is also available for compatibility.
@@ -2270,7 +2270,7 @@ Map class
 .. js:attribute:: Map._dir
 
   See the HAProxy configuration.txt file, chapter "Using ACLs and fetching
-  samples" ans subchapter "ACL basics" to understand this pattern matching
+  samples" and subchapter "ACL basics" to understand this pattern matching
   method.
 
   Note that :js:attr:`Map.dir` is also available for compatibility.
@@ -2278,7 +2278,7 @@ Map class
 .. js:attribute:: Map._dom
 
   See the HAProxy configuration.txt file, chapter "Using ACLs and fetching
-  samples" ans subchapter "ACL basics" to understand this pattern matching
+  samples" and subchapter "ACL basics" to understand this pattern matching
   method.
 
   Note that :js:attr:`Map.dom` is also available for compatibility.
@@ -2286,13 +2286,13 @@ Map class
 .. js:attribute:: Map._end
 
   See the HAProxy configuration.txt file, chapter "Using ACLs and fetching
-  samples" ans subchapter "ACL basics" to understand this pattern matching
+  samples" and subchapter "ACL basics" to understand this pattern matching
   method.
 
 .. js:attribute:: Map._reg
 
   See the HAProxy configuration.txt file, chapter "Using ACLs and fetching
-  samples" ans subchapter "ACL basics" to understand this pattern matching
+  samples" and subchapter "ACL basics" to understand this pattern matching
   method.
 
   Note that :js:attr:`Map.reg` is also available for compatibility.
@@ -2370,7 +2370,7 @@ AppletHTTP class
 
   This attribute contains a Fetches class object. Note that the
   applet execution place cannot access to a valid HAProxy core HTTP
-  transaction, so some sample fetches related to the HTTP dependant
+  transaction, so some sample fetches related to the HTTP dependent
   values (hdr, path, ...) are not available.
 
 .. js:attribute:: AppletHTTP.sf
@@ -2380,7 +2380,7 @@ AppletHTTP class
   This attribute contains a Fetches class object. The functions of
   this object returns always a string. Note that the applet
   execution place cannot access to a valid HAProxy core HTTP
-  transaction, so some sample fetches related to the HTTP dependant
+  transaction, so some sample fetches related to the HTTP dependent
   values (hdr, path, ...) are not available.
 
 .. js:attribute:: AppletHTTP.method
@@ -2451,7 +2451,7 @@ AppletHTTP class
   This function add an header in the response. Duplicated headers are not
   collapsed. The special header *content-length* is used to determinate the
   response length. If it not exists, a *transfer-encoding: chunked* is set, and
-  all the write from the funcion *AppletHTTP:send()* become a chunk.
+  all the write from the function *AppletHTTP:send()* become a chunk.
 
   :param class_AppletHTTP applet: An :ref:`applethttp_class`
   :param string name: the header name
@@ -2821,7 +2821,7 @@ A lot of useful lua libraries can be found here:
 
 * `https://lua-toolbox.com/ <https://lua-toolbox.com/>`_
 
-Redis acces:
+Redis client library:
 
 * `https://github.com/nrk/redis-lua <https://github.com/nrk/redis-lua>`_
 

doc/lua.txt

@@ -26,7 +26,7 @@ Why a scripting language in HAProxy
 
 HAProxy 1.5 makes at possible to do many things using samples, but some people
 want to more combining results of samples fetches, programming conditions and
-loops which is not possible. Sometimes people implement these functionnalities
+loops which is not possible. Sometimes people implement these functionalities
 in patches which have no meaning outside their network. These people must
 maintain these patches, or worse we must integrate them in the HAProxy
 mainstream.
@@ -285,7 +285,7 @@ Some examples follows. This first one, is a simple addition:
    lua_arith(L, LUA_OPADD)
 
 It's easy, we push 1 on the stack, after, we push 2, and finally, we perform an
-addition. The two top entries of the stack are added, poped, and the result is
+addition. The two top entries of the stack are added, popped, and the result is
 pushed. It is a classic way with a stack.
 
 Now an example for constructing array and objects. It's a little bit more