One request that often comes from customers is to provide persistence based on a server issued cookie, such as jsessionid.  The following configuration example has been passed around for a while for this purpose:

 

set lb vserver <vserver name>

  -persistenceType RULE -timeout 180

  -rule http.req.header(“cookie”).value(0).typecast_nvlist_t(‘=’,’;’).value(“JSESSIONID”)
  -resrule http.res.header(“set-cookie”).value(0).typecast_nvlist_t(‘=’,’;’).value(“JSESSIONID”)

 

Unfortunately, this example has a few drawbacks.  First, if there is more than one set-cookie header in the response, and the cookie desired isn’t in the first header, then it will be missed and persistence will be broken.  The second is that it is overly complex to visually understand.  Since this example was created, additional operators were added to the AppExpert engine in order to improve the usability and utility of this commonly needed function, and has allows us to use the following as a more generic jsessionid policy set:

 

  -rule “HTTP.REQ.COOKIE.VALUE(\”jsessionid\”) ALT HTTP.REQ.URL.BEFORE_STR(\”?\”).AFTER_STR(\”;jsessionid=\”) ALT HTTP.REQ.URL.AFTER_STR(\”;jsessionid=\”)”

  -resRule “HTTP.RES.SET_COOKIE.COOKIE(\”jsessionid\”).VALUE(\”jsessionid\”)”

 

This new policy handles more cases, and is cleaner to understand.

 

On the request side, there are two situations handled:

1)       the jsessionid is presented in a cookie (the normal case)

2)       the jsessionid can be presented in the URL in a format such as “/index.jsp;jsessionid=x?q=1”

 

This URL placement is used for applications that have clients that don’t support cookies, or don’t handle them properly, such as some older cell phones and embedded applications.  While not commonly encountered, having a generic policy that covers this situation may help insure that a system doesn’t break when code changes, and as such is recommended for systems that rely on jsessionid.  The response side processing is fairly straight forward.