Details on load balancer stickyness
The module modproxybalancer implements stickyness on top of two alternative means: cookies and URL encoding. Providing the cookie can be either done by the back-end or by the Apache web server itself. The URL encoding is usually done on the back-end. Examples of a balancer configuration. Modproxyhtml is an output filter to rewrite HTML links in a proxy situation, to ensure that links work for users outside the proxy. It serves the same purpose as Apache's ProxyPassReverse directive does for HTTP headers, and is an essential component of a reverse proxy.
Libapache2 Mod Proxy Html
When using cookie based stickyness, you need to configure the name of the cookie that contains the information about which back-end to use. This is done via the stickysession attribute added to either
ProxySet. The name of the cookie is case-sensitive. The balancer extracts the value of the cookie and looks for a member worker with route equal to that value. The route must also be set in either
ProxySet. The cookie can either be set by the back-end, or as shown in the above example by the Apache web server itself.
Some back-ends use a slightly different form of stickyness cookie, for instance Apache Tomcat. Tomcat adds the name of the Tomcat instance to the end of its session id cookie, separated with a dot (
.) from the session id. Thus if the Apache web server finds a dot in the value of the stickyness cookie, it only uses the part behind the dot to search for the route. In order to let Tomcat know about its instance name, you need to set the attribute
jvmRoute inside the Tomcat configuration file
conf/server.xml to the value of the route of the worker that connects to the respective Tomcat. The name of the session cookie used by Tomcat (and more generally by Java web applications based on servlets) is
JSESSIONID (upper case) but can be configured to something else.
The second way of implementing stickyness is URL encoding. The web server searches for a query parameter in the URL of the request. The name of the parameter is specified again using stickysession. The value of the parameter is used to lookup a member worker with route equal to that value. Since it is not easy to extract and manipulate all URL links contained in responses, generally the work of adding the parameters to each link is done by the back-end generating the content. In some cases it might be feasible doing this via the web server using
mod_sed. This can have negative impact on performance though.
The Java standards implement URL encoding slightly different. They use a path info appended to the URL using a semicolon (
;) as the separator and add the session id behind. As in the cookie case, Apache Tomcat can include the configured
jvmRoute in this path info. To let Apache find this sort of path info, you need to set
Finally you can support cookies and URL encoding at the same time, by configuring the name of the cookie and the name of the URL parameter separated by a vertical bar (
) as in the following example:
Go Mod Proxy
If the cookie and the request parameter both provide routing information for the same request, the information from the request parameter is used.