PDA

View Full Version : Diffrence between redirect: and RedirectView


akram
Mar 21st, 2006, 06:03 AM
Hello all,

I am using some redirection after posts in my application. I am facing a problem with redirect views. I have a reverse proxy based architecture, and this is causing me a few problems with redirection.

So, while investigating, I found that there is 2 ways to perform redictions with Spring:
redirect:
and
return ModelAndView(new RedirectView(getSuccessView()))
I found nothing about the first way. Could someone please explain me what the difference between between redirect: and RedirectView ?

greetings
Akram

Colin Yates
Mar 21st, 2006, 06:41 AM
I would suggest using RedirectView as it is IMO cleaner and more explicit.
Controllers should not worry about the mechanisms of the view implementation, however specifying "redirect:" leaks this information into the controller.
Changing the view to be XML/XSLT/freemarker etc. suddenly breaks the controller.

redirect: BTW is a keyword supported by UrlBasedViewResolver.

eting
Apr 3rd, 2006, 04:56 AM
Hi,
I'm having the same problem. Just wondering if you have found the solution, and if you mind sharing with me?

I've been using RedirectViews, but they are causing me problems in a reverse-proxy configuration. I have Squid configured as a reverse proxy that listens to port 443 for https:// requests, and it forwards to a tomcat internal web server. Whenever I use redirects, there is a problem constructing the https:// url again....

I have specified something like this in my views.properties:
changePasswordRedirect.class=org.springframework.w eb.servlet.view.RedirectView
changePasswordRedirect.url=changePassword.html

And this is returned in my onSubmit:
return new ModelAndView("changePasswordRedirect", "command", backingObject);

Thanks in advance,
E

akram
Apr 3rd, 2006, 05:19 AM
Hello,

we finally find out the problem. Just like you, we were using also HTTPS with our reverse proxy.
First, for this case, I can confirm that this problem is NOT a spring redirection implementation problem.

Our problem was due to a misconfiguration of the Apache Reverse Proxy. Our provider did not setup the ProxyPassReverse directive on it. I don't know if there is an equivalent feature on squid, but I guess that it does. This option, allows the reverse proxy to change the Location header on the request, to allow the server to ask for the correct complete URL after the redirection. You can note, that the behaviour of firefox and IE are not the same for a redirection behind a reverse proxy. IE does not take care that the Location has changed, and performs the redirection on the same server that the one that has originated the redirect. This could be a security hole for phishing. At the other end, when FF sees a redirect, he reads the Location header again and ask for the complete URL.


The second problem we faced, was due to a bug in the mod_ssl of apache v2.0.55. After submittng a file upload, we got a NullPointerException with FF (not with IE, another difference of implementation maybe). It is a known bug in apache, it has been resovled on 2.2 but still not backported to 2.0.
I don't think that this is your problem here, but this could help.

eting
Apr 4th, 2006, 02:26 PM
Thanks a lot for the reply!

Before getting your reply, I was actually trying to re-do all the 'redirects' as 'forwards', but they were causing me other problems.

Now we are trying to figure out if we have equivalent options in Squid, it looks like we may have to use the Squirm Redirector or something...still investigating...

akram
Apr 5th, 2006, 07:49 AM
I also wanted first to replace the Redirect by Forward, but I realized that it will take to me a very long time. And, since my webapp has been succesffully tested on developement, I didn't want to rewrite it !

The other problem I faced, was about posting data and the back button. The RedirectView does not cause the problem in these cases, when the forward asks to repost the form.
With sensitive forms, I prefer using the Redirect.

eting
Apr 5th, 2006, 01:02 PM
Same here, we thought it didn't make sense for us to re-do the development work. After spending another day on it yesterday, we decided to switch to Apache..