Spring MVC "redirect:" prefix always redirects to http -- how do I make it stay on https?

Question

I solved this myself, but I spent so long discovering such a simple solution, I figured it deserved to be documented here.

I have a typical Spring 3 MVC setup with an InternalResourceViewResolver:

<bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver">   <property name="viewClass" value="org.springframework.web.servlet.view.JstlView" />   <property name="prefix" value="/" />   <property name="suffix" value=".jsp" /> </bean> 

I have a pretty simple handler method in my controller, but I've simplified it even more for this example:

@RequestMapping("/groups") public String selectGroup() {     return "redirect:/"; } 

The problem is, if I browse to https://my.domain.com/groups, I end up at http://my.domain.com/ after the redirect. (In actuality my load-balancer redirects all http requests to https, but this just causes multiple browser alerts of the type "You are leaving/entering a secure connection" for folks who have such alerts turned on.)

So the question is: how does one get spring to redirect to https when that's what the original request used?

Answer 1

The short answer is, set the InternalResourceViewResolver's redirectHttp10Compatible property to false:

<bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver">   <property name="viewClass" value="org.springframework.web.servlet.view.JstlView" />   <property name="prefix" value="/" />   <property name="suffix" value=".jsp" />   <property name="redirectHttp10Compatible" value="false" /> </bean> 

You could do this on a per-request basis instead, by having your handler method return View instead of String, and creating the RedirectView yourself, and calling setHttp10Compatible(false).

(It turns out the culprit is HttpServletResponse.sendRedirect, which the RedirectView uses for HTTP 1.0 compatible redirects, but not otherwise. I guess this means it's dependent on your servlet container's implementation (?); I observed the problem in both Tomcat and Jetty.)