From: Tim Düsterhus <t...@bastelstu.be> --- CONTRIBUTING | 22 +++++++++++----------- doc/configuration.txt | 26 +++++++++++++------------- doc/haproxy.1 | 2 +- src/backend.c | 2 +- src/checks.c | 6 +++--- src/proto_tcp.c | 2 +- src/proto_uxst.c | 2 +- 7 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/CONTRIBUTING b/CONTRIBUTING index 968da4f..ddeb4ea 100644 --- a/CONTRIBUTING +++ b/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 - maintainers whose address is mentionned in a MAINTAINERS file. Not everyone + important to CC any author mentioned in the file you change, or a subsystem + 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.. diff --git a/doc/configuration.txt b/doc/configuration.txt index 6e3cbaa..f28b029 100644 --- a/doc/configuration.txt +++ b/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 (section 9) from all details on the supported parameters. + filter. Please refer to the documentation of the corresponding + 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 completement 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: diff --git a/doc/haproxy.1 b/doc/haproxy.1 index 3202a6a..0a1b2f5 100644 --- a/doc/haproxy.1 +++ b/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 diff --git a/src/backend.c b/src/backend.c index d34b5ec..57f811f 100644 --- a/src/backend.c +++ b/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. */ diff --git a/src/checks.c b/src/checks.c index 61d3768..8eb2c7a 100644 --- a/src/checks.c +++ b/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). */ diff --git a/src/proto_tcp.c b/src/proto_tcp.c index f1e3b60..f6d8ca1 100644 --- a/src/proto_tcp.c +++ b/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. diff --git a/src/proto_uxst.c b/src/proto_uxst.c index b2a7fe2..5c8f9d4 100644 --- a/src/proto_uxst.c +++ b/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. -- 2.10.2