DOC: assorted typo fixes in the documentation
This is the third round of cleanups in various docs
diff --git a/doc/design-thoughts/entities-v2.txt b/doc/design-thoughts/entities-v2.txt
index 905888e..91c4fa9 100644
--- a/doc/design-thoughts/entities-v2.txt
+++ b/doc/design-thoughts/entities-v2.txt
@@ -119,7 +119,7 @@
- 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)
diff --git a/doc/design-thoughts/http2.txt b/doc/design-thoughts/http2.txt
index 20a5c54..c21ac10 100644
--- a/doc/design-thoughts/http2.txt
+++ b/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.
diff --git a/doc/internals/buffer-api.txt b/doc/internals/buffer-api.txt
index 6d192c1..14a1ac7 100644
--- a/doc/internals/buffer-api.txt
+++ b/doc/internals/buffer-api.txt
@@ -630,7 +630,7 @@
<------------------> <---------->
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
diff --git a/doc/internals/entities-v2.txt b/doc/internals/entities-v2.txt
index 38d633d..86782c3 100644
--- a/doc/internals/entities-v2.txt
+++ b/doc/internals/entities-v2.txt
@@ -116,7 +116,7 @@
- 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)
diff --git a/doc/internals/entities.txt b/doc/internals/entities.txt
index d384395..cdde82e 100644
--- a/doc/internals/entities.txt
+++ b/doc/internals/entities.txt
@@ -9,7 +9,7 @@
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 @@
Initiator
---------
-An initiator is instanciated for each incoming connection on a listener. It may
-also be instanciated by a task pretending to be a client. An initiator calls
+An initiator is instantiated for each incoming connection on a listener. It may
+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 @@
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 @@
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 @@
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.
diff --git a/doc/internals/filters.txt b/doc/internals/filters.txt
index 7705ee2..e49668a 100644
--- a/doc/internals/filters.txt
+++ b/doc/internals/filters.txt
@@ -84,7 +84,7 @@
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 @@
---------------------
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 @@
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 @@
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 @@
*
* 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 @@
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 @@
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 @@
}
-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
diff --git a/doc/internals/htx-api.txt b/doc/internals/htx-api.txt
index 7783b0c..77bbec9 100644
--- a/doc/internals/htx-api.txt
+++ b/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 @@
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 @@
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 @@
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 @@
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.
diff --git a/doc/internals/notes-layers.txt b/doc/internals/notes-layers.txt
index 7ca51fe..541c125 100644
--- a/doc/internals/notes-layers.txt
+++ b/doc/internals/notes-layers.txt
@@ -110,7 +110,7 @@
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 @@
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 @@
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.
diff --git a/doc/lua-api/index.rst b/doc/lua-api/index.rst
index b4c3a2b..9a578ee 100644
--- a/doc/lua-api/index.rst
+++ b/doc/lua-api/index.rst
@@ -311,7 +311,7 @@
**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 @@
: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 @@
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 @@
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 @@
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 @@
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 @@
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 @@
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 @@
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 @@
.. 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 @@
.. 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 @@
.. 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 @@
.. 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 @@
.. 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 @@
.. 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 @@
.. 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 @@
.. 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 @@
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 @@
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 @@
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 @@
* `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>`_
diff --git a/doc/lua.txt b/doc/lua.txt
index a0a1d61..0d06fa3 100644
--- a/doc/lua.txt
+++ b/doc/lua.txt
@@ -26,7 +26,7 @@
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 @@
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