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
Are you sure?
Looking at the code it seems there is no difference. Both variants call response.encodeRedirectURL(targetUrl), see Line 388 of RedirectView:
if (http10Compatible) {
// Always send status code 302.
response.sendRedirect(response.encodeRedirectURL(targetUrl));
}
else {
HttpStatus statusCode = getHttp11StatusCode(request, response, targetUrl);
response.setStatus(statusCode.value());
response.setHeader("Location", response.encodeRedirectURL(targetUrl));
}
I had the same problem, but it was triggered by setting up tomcat behind a loadbalancer. The loadbalancer does the SSL handshake and forwards to tomcat a plain http connection.
Solution would be to send a special Http Header in your Loadbalancer, so tomcat can "trust" this connection. Using a servlet filter should set response.isSecure flag. Then overwrite RedirectView to see if response.isSecure and handle it the right way.
I kept this solution short because i am not sure if it machtes the question.