DOC: fix "workaround" spelling

"a workaround", "to work around", and not "to walk around".
Thanks to Lukas for reporting.
This commit is contained in:
Willy Tarreau 2016-01-15 10:26:26 +01:00
parent cc123c66c2
commit 989222acff
2 changed files with 5 additions and 5 deletions

View File

@ -472,7 +472,7 @@ dead. Of course, you can simply enable TCP health-checks, but it sometimes
happens that intermediate firewalls between the proxies and the remote servers
acknowledge the TCP connection themselves, showing an always-up server. Since
this is generally encountered on long-distance communications, which often
involve SSL, an SSL health-check has been implemented to workaround this issue.
involve SSL, an SSL health-check has been implemented to work around this issue.
It sends SSL Hello messages to the remote server, which in turns replies with
SSL Hello messages. Setting it up is very easy :
@ -1307,7 +1307,7 @@ persistent connections per user).
Even if you disable keep-alive, if the server takes a long time to respond,
you still have a high risk of multiple users clicking at the same time and
having their requests unserved because of server saturation. To walk around
having their requests unserved because of server saturation. To work around
the problem, you increase the concurrent connection limit on the servers,
but their performance stalls under higher loads.

View File

@ -2926,7 +2926,7 @@ errorfile <code> <file>
Example :
errorfile 400 /etc/haproxy/errorfiles/400badreq.http
errorfile 408 /dev/null # workaround Chrome pre-connect bug
errorfile 408 /dev/null # work around Chrome pre-connect bug
errorfile 403 /etc/haproxy/errorfiles/403forbid.http
errorfile 503 /etc/haproxy/errorfiles/503sorry.http
@ -2956,7 +2956,7 @@ errorloc302 <code> <url>
client to fetch the designated URL using the same HTTP method. This can be
quite problematic in case of non-GET methods such as POST, because the URL
sent to the client might not be allowed for something other than GET. To
workaround this problem, please use "errorloc303" which send the HTTP 303
work around this problem, please use "errorloc303" which send the HTTP 303
status code, indicating to the client that the URL must be fetched with a GET
request.
@ -10128,7 +10128,7 @@ agent-check
parameter. Warning though, it is not a good idea to stop an agent after it
reports "down", since only an agent reporting "up" will be able to turn the
server up again. Note that the CLI on the Unix stats socket is also able to
force an agent's result in order to workaround a bogus agent if needed.
force an agent's result in order to work around a bogus agent if needed.
Requires the "agent-port" parameter to be set. See also the "agent-inter"
parameter.