F5 load balancer and Tomcat 302 error


The following article offers some suggestions on solving the following issue.

You may be running F5 big IP's and offloading SSL at the load balancer. This means behind the load balancer you might have JasperServer running on HTTP only. The load balancer VIP is SSL only.  A request may come in over https terminating at the load balancer, the selected JasperServer will return the request but as unencrypted, which may not work.

One option may be to create a set of rewrite rules at the load balancer to fix this.  Or, you can pass SSL all the way through.  These options may not be feasible.  Consider the alternatives below.

The general scenario of the problem is,

  1. Goto https://jasperurl/jasperserver-pro/login.html
  2. Login
  3. A page request is made to https://jasperurl/jasperserver-pro/j_spring_security_check
  4. Said page issues a 302 upon successful login to http://jasperurl/jasperserver-pro/loginsuccess.html
  5. End up at http://jasperurl/jasperserver-pro/flow.html?_flowId=homeFlow
  6. If you change http to https, navigation resumes under https and works until you log out which causes the same https to http issue.

There are 302's being passed back to the client explicitly rewriting back to
http. This appears to be coming from the source and is either being generated by code or tomcat.

Tomcat converts all 302's into absolute URL's, so as the behind the scenes
requests are http, it redirects absolutes to http.  Apparently this can be
overwritten by recompiling tomcat to allow org.apache.catalina.connector.Response to use relative URLs instead of absolute only.



Jaspersoft believes this is a Tomcat implementation that uses absolute URLs for redirects because it's mandated by the HTTP RFC, see https://tools.ietf.org/html/rfc2068#section-14.30

You may be able to get around it using iRules. There is also an option in LTM to handle rewriting of redirects in the http profile.

Also see the following links for additional information that may be relevant to your situation.

Ref. Case #00025117 -- 23:51, 15 March 2012 (UTC)