Satya Komatineni's Blog

Rewriting SendRedirect to deal with SSL (or https) offloading

When "sendRedirect" is used, some times the relative url is being translated into an absolute url using wrong scheme (http vs https). This articles explores the problem and a possible solution using servlet filters.

Rewriting SendRedirect to deal with SSL (or https) offloading

Comments

• The approach expolored at that URL is ignorant of a fact that some (many?) websites have to combine HTTPS and HTTP traffic. Proposed filter will turn _all_ redirect URLs into HTTPS, which is a bit crude. Those SSL/TLS offload devices have a nice feature though, they are capable of appending a header to request, or they can be configured to communicate with app server on a different port. X-Secure is frequently used and this header, when set, should make HttpServletRequest.isSecure() to return true. When decision on whether to modify request scheme while constructing redirect URL is made based on isSecure(), then it is a more acceptable behavior. Besides, having isSecure() to still report "false" in such a context is a big bad inconsistency.

  So, to recount, the proposed filter does not alter isSecure(), getScheme(), and getServerPort() and is broken as such :)

  Another aspects of "pure" request that offloading/load-balancing solutions obscure are server name and remote IP address. Comprehensive solution should take care of those, too.

  Posted by: denka on April 12, 2006 at 10:28 AM

• Thanks for the valuable information.
  A comprehensive solution should address all those.
  

  Posted by: satyak on April 12, 2006 at 10:50 AM

This work is licensed under a Creative Commons License.