There is a well known problem of keeping a session bound to one physical real server after the session is setup on HTTP (open) transport and later moved to HTTPS (secure) transport protocol. In this case, the HTTP redirection should be setup at the application level. The server can send a redirect (either a 302 or an HREF embedded in the actual web page itself) to HTTP, so no load balancing takes place at the Local Director. Another possible solution would be to switch to HTTPS sooner, and perform the session opening encrypted. This is preferred also for encrypting the login username and password. If you keep the whole session running via HTTPS, the generic sticky can ensure that the same server will be used for a client. The second solution and configuration is described in this document. The HTTP traffic is limited to first contact with the site (the client can type simple site name to address bar). When reaching Local Director, the browser receives a 302 redirect message with the URL configured, including the HTTPS tag, so there is the complete name of the server to reach. The session (on application level) is built from the beginning with the secure server (the real servers do not handle HTTP at all). Tthe session continues with the unique server name, so it is always reaching the same.
http://cisco.com/en/US/products/hw/contnetw/ps1894/products_configuration_example09186a00801a7299.shtml#maintask1