"option redispatch" remains vague in which cases a session would persist; let's mention "option persist" and "force-persist" as an example so folks don't draw the conclusion that this may be default.
Should be backported to stable branches. --- doc/configuration.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/doc/configuration.txt b/doc/configuration.txt index 7c208c47d1..56d088364c 100644 --- a/doc/configuration.txt +++ b/doc/configuration.txt @@ -10875,7 +10875,8 @@ no option redispatch In HTTP mode, if a server designated by a cookie is down, clients may - definitely stick to it because they cannot flush the cookie, so they will not + definitely stick to it, for example when using "option persist" or + "force-persist", because they cannot flush the cookie, so they will not be able to access the service anymore. Specifying "option redispatch" will allow the proxy to break cookie or @@ -10908,7 +10909,7 @@ no option redispatch If this option has been enabled in a "defaults" section, it can be disabled in a specific instance by prepending the "no" keyword before it. - See also : "retries", "force-persist" + See also : "option persist", "force-persist", "retries" option redis-check -- 2.17.1
