This is a pretty lame commit in a attempt to use a common wording of HAProxy used 1319 times compared to HAproxy used 18 times --- contrib/syntax-highlight/haproxy.vim | 2 +- doc/SPOE.txt | 2 +- doc/architecture.txt | 2 +- doc/internals/htx-api.txt | 2 +- doc/lua-api/index.rst | 8 ++++---- doc/lua.txt | 6 +++--- doc/regression-testing.txt | 10 +++++----- src/mailers.c | 2 +- src/mux_fcgi.c | 2 +- 9 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/contrib/syntax-highlight/haproxy.vim b/contrib/syntax-highlight/haproxy.vim index 48fd78c637f1..02c323255190 100644 --- a/contrib/syntax-highlight/haproxy.vim +++ b/contrib/syntax-highlight/haproxy.vim @@ -1,5 +1,5 @@ " Vim syntax file -" Language: HAproxy +" Language: HAProxy " Maintainer: Bruno Michel <[email protected]> " Last Change: Mar 30, 2007 " Version: 0.3 diff --git a/doc/SPOE.txt b/doc/SPOE.txt index dfc0b718b8e3..9c0ae6be237e 100644 --- a/doc/SPOE.txt +++ b/doc/SPOE.txt @@ -749,7 +749,7 @@ Here are the list of official capabilities that HAProxy and agents can support: * pipelining: This is the ability for a peer to decouple NOTIFY and ACK frames. This is a symmectical capability. To be used, it must - be supported by HAproxy and agents. Unlike HTTP pipelining, the + be supported by HAProxy and agents. Unlike HTTP pipelining, the ACK frames can be send in any order, but always on the same TCP connection used for the corresponding NOTIFY frame. diff --git a/doc/architecture.txt b/doc/architecture.txt index f359dd7f11b6..6b122e858a09 100644 --- a/doc/architecture.txt +++ b/doc/architecture.txt @@ -665,7 +665,7 @@ Description : When an application is spread across several servers, the time to update all instances increases, so the application seems jerky for a longer period. -HAproxy offers several solutions for this. Although it cannot be reconfigured +HAProxy offers several solutions for this. Although it cannot be reconfigured without being stopped, nor does it offer any external command, there are other working solutions. diff --git a/doc/internals/htx-api.txt b/doc/internals/htx-api.txt index 32cfd1e4125c..d2dc87b012af 100644 --- a/doc/internals/htx-api.txt +++ b/doc/internals/htx-api.txt @@ -295,7 +295,7 @@ buffer. There are 2 functions to do so, the second one relying on the first: Both functions return a "zero-sized" HTX message if the buffer is null. This way, you are sure to always have a valid HTX message. The first function is the default function to use. The second one is only useful when some content will be -added. For instance, it used by the HTX analyzers when HAproxy generates a +added. For instance, it used by the HTX analyzers when HAProxy generates a response. This way, the buffer is in a right state and you don't need to take care of it anymore outside the possible error paths. diff --git a/doc/lua-api/index.rst b/doc/lua-api/index.rst index fb7eb0978caf..e0bda2dc8963 100644 --- a/doc/lua-api/index.rst +++ b/doc/lua-api/index.rst @@ -488,7 +488,7 @@ Core class end) .. - This example code is used in HAproxy configuration like this: + This example code is used in HAProxy configuration like this: :: @@ -511,7 +511,7 @@ Core class core.register_action("hello-world", { "tcp-req", "http-req" }, hello_world, 2) .. - This example code is used in HAproxy configuration like this: + This example code is used in HAProxy configuration like this: :: @@ -635,7 +635,7 @@ Core class end) .. - This example code is used in HAproxy configuration like this: + This example code is used in HAProxy configuration like this: :: @@ -2808,7 +2808,7 @@ Action class This attribute is an integer (6). It aborts the current message. The message processing is stopped and the transaction is terminated. For HTTP streams, - HAproxy assumes a response was already sent to the client. From the Lua + HAProxy assumes a response was already sent to the client. From the Lua actions point of view, when this code is used, the transaction is terminated with no reply. diff --git a/doc/lua.txt b/doc/lua.txt index 9bf9f144d9b0..87b6af423010 100644 --- a/doc/lua.txt +++ b/doc/lua.txt @@ -384,7 +384,7 @@ object name. The Lua developer can add entries to the HAProxy object. They just work carefully and prevent to modify the index [0]. -Common HAproxy objects are: +Common HAProxy objects are: - TXN : manipulates the transaction between the client and the server - Channel : manipulates proxified data between the client and the server @@ -488,7 +488,7 @@ yield must be jump to the root of execution. The intermediate setjmp() avoids this behaviour. - HAproxy start Lua execution + HAProxy start Lua execution + Lua puts a setjmp() + Lua executes code + Some code is executed in a pcall() @@ -515,7 +515,7 @@ after a yield. These parts are the sample fetches and the sample converters. So, the Lua code written in these parts of HAProxy must be quickly executed, and can not do actions which require yield like TCP connection or simple sleep. -HAproxy socket object +HAProxy socket object --------------------- The HAProxy design is optimized for the data transfers between a client and a diff --git a/doc/regression-testing.txt b/doc/regression-testing.txt index 1b6c21d10bb7..ad94211d4b31 100644 --- a/doc/regression-testing.txt +++ b/doc/regression-testing.txt @@ -179,7 +179,7 @@ status. Here is the output when running this VTC file: **** h1 0.0 macro def h1_pid=6395 **** h1 0.0 macro def h1_name=/tmp/vtc.6377.64329194/h1 ** h1 0.0 Wait - ** h1 0.0 Stop HAproxy pid=6395 + ** h1 0.0 Stop HAProxy pid=6395 **** h1 0.0 STDOUT poll 0x10 ** h1 0.0 WAIT4 pid=6395 status=0x008b (user 0.000000 sys 0.000000) * h1 0.0 Expected exit: 0x1 signal: 0 core: 0 @@ -227,7 +227,7 @@ as expected (verbose mode execution): **** h1 0.0 macro def h1_pid=25558 **** h1 0.0 macro def h1_name=/tmp/vtc.25540.59b6ec5d/h1 ** h1 0.0 Wait - ** h1 0.0 Stop HAproxy pid=25558 + ** h1 0.0 Stop HAProxy pid=25558 *** h1 0.0 debug|[ALERT] 157/135318 (25558) : parsing [/tmp/vtc.25540.59b6ec5d/h1/cfg:10] : 'filter' : ''spoe' : missing config file' *** h1 0.0 debug|[ALERT] 157/135318 (25558) : Error(s) found in configuration file : /tmp/vtc.25540.59b6ec5d/h1/cfg *** h1 0.0 debug|[ALERT] 157/135318 (25558) : Fatal errors found in configuration. @@ -318,7 +318,7 @@ client and 's1' server with 'http1' as haproxy frontend. This frontend listen on TCP socket with 'my_frontend_fd' as file descriptor. # Mandatory line - varnishtest "Basic HAproxy test" + varnishtest "Basic HAProxy test" # As some macros for haproxy are used in this file, this line is mandatory. feature ignore_unknown_macro @@ -558,7 +558,7 @@ Here is the output produced by varnishtest with the latter VTC file: * top 0.0 RESETTING after /home/fred/src/varnish-cache-haproxy/d02286d.vtc ** h1 0.0 Reset and free h1 haproxy 15787 ** h1 0.0 Wait - ** h1 0.0 Stop HAproxy pid=15787 + ** h1 0.0 Stop HAProxy pid=15787 **** h1 0.0 Kill(2)=0: Success **** h1 0.0 STDOUT poll 0x10 ** h1 0.1 WAIT4 pid=15787 status=0x0002 (user 0.000000 sys 0.004000) @@ -693,7 +693,7 @@ of the "syslog" "expect" command: * top 0.0 RESETTING after /home/fred/src/varnish-cache-haproxy/d02286d.vtc ** h1 0.0 Reset and free h1 haproxy 12728 ** h1 0.0 Wait - ** h1 0.0 Stop HAproxy pid=12728 + ** h1 0.0 Stop HAProxy pid=12728 **** h1 0.0 Kill(2)=0: Success **** h1 0.0 STDOUT poll 0x10 ** h1 0.1 WAIT4 pid=12728 status=0x0002 (user 0.000000 sys 0.004000) diff --git a/src/mailers.c b/src/mailers.c index 76d6a69ea86f..7d84bf43ebdf 100644 --- a/src/mailers.c +++ b/src/mailers.c @@ -239,7 +239,7 @@ static int enqueue_one_email_alert(struct proxy *p, struct server *s, "From: ", p->email_alert.from, "\r\n", "To: ", p->email_alert.to, "\r\n", "Date: ", datestr, "\r\n", - "Subject: [HAproxy Alert] ", msg, "\r\n", + "Subject: [HAProxy Alert] ", msg, "\r\n", "\r\n", msg, "\r\n", "\r\n", diff --git a/src/mux_fcgi.c b/src/mux_fcgi.c index 9998710f0fde..683afe3b62fa 100644 --- a/src/mux_fcgi.c +++ b/src/mux_fcgi.c @@ -60,7 +60,7 @@ #define FCGI_CF_ABRTS_SENT 0x00000200 /* a record ABORT was successfully sent to all active streams */ #define FCGI_CF_ABRTS_FAILED 0x00000400 /* failed to abort processing of all streams */ #define FCGI_CF_WAIT_FOR_HS 0x00000800 /* We did check that at least a stream was waiting for handshake */ -#define FCGI_CF_KEEP_CONN 0x00001000 /* HAproxy is responsible to close the connection */ +#define FCGI_CF_KEEP_CONN 0x00001000 /* HAProxy is responsible to close the connection */ #define FCGI_CF_GET_VALUES 0x00002000 /* retrieve settings */ /* FCGI connection state (fcgi_conn->state) */
