diff --git a/BRANCHES b/BRANCHES index 521c0ee1f..6cb275c94 100644 --- a/BRANCHES +++ b/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. diff --git a/doc/design-thoughts/entities-v2.txt b/doc/design-thoughts/entities-v2.txt index 905888e22..91c4fa97e 100644 --- a/doc/design-thoughts/entities-v2.txt +++ b/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) diff --git a/doc/design-thoughts/http2.txt b/doc/design-thoughts/http2.txt index 20a5c54c4..c21ac108a 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 6d192c19d..14a1ac77f 100644 --- a/doc/internals/buffer-api.txt +++ b/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 diff --git a/doc/internals/entities-v2.txt b/doc/internals/entities-v2.txt index 38d633d20..86782c34d 100644 --- a/doc/internals/entities-v2.txt +++ b/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) diff --git a/doc/internals/entities.txt b/doc/internals/entities.txt index d384395f1..cdde82e34 100644 --- a/doc/internals/entities.txt +++ b/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 -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 @@ 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. diff --git a/doc/internals/filters.txt b/doc/internals/filters.txt index 7705ee2b6..e49668a8b 100644 --- a/doc/internals/filters.txt +++ b/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, and are offets representing amount of + * channel. Especially, and 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 diff --git a/doc/internals/htx-api.txt b/doc/internals/htx-api.txt index 7783b0c7f..77bbec9bd 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 @@ 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. diff --git a/doc/internals/notes-layers.txt b/doc/internals/notes-layers.txt index 7ca51fe52..541c12582 100644 --- a/doc/internals/notes-layers.txt +++ b/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. diff --git a/doc/lua-api/index.rst b/doc/lua-api/index.rst index b4c3a2b32..9a578ee29 100644 --- a/doc/lua-api/index.rst +++ b/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/ `_ -Redis acces: +Redis client library: * `https://github.com/nrk/redis-lua `_ diff --git a/doc/lua.txt b/doc/lua.txt index a0a1d6180..0d06fa39e 100644 --- a/doc/lua.txt +++ b/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