> -----Original Message----- > From: Jing Zhou [mailto:[EMAIL PROTECTED] > Sent: June 28, 2003 10:28 AM > To: Struts Users Mailing List > Subject: Re: Sending a Redirect Directly from an Action Class > > > I have the following concerns whenever the redirect is used: > > * The statement response.sendRedirect("/somePage.jsp") > will bind the codes statically to the underlying file system > structures. So if someone moves the somePage.jsp to > a different location, the codes are broken.
Yes, there's nothing gained by hard coding the redirect in the action class and it's easier and more flexible to use redirect=true on an ActionForward. > > * The JSP page somePage.jsp could not be protected > by the standard security constraints. So it is recommended > to use response.sendRedirect("/someAction.do") or > a Filter, either way that provides security checking. > Improper use of the redirect could make the security > constraints over complicated as in an early discussion on > how we redirect to restricted pages. > This is not true. When you redirect the client issues a new request which is subject to container managed security. (You can set up a rule to protect /somePage.jsp as easily as you can /someAction.do. When you *forward* a request, this happens within the container and does not trigger security rules. > * Use the redirect only when it is really needed. It needs > extra CPU time and network resources than just forward. > Technically true, because it does create an extra round-trip between client and server. But the overall effect is negligible. About as much as your user clicking on a link to go to another page and I think most servers should be able to handle that ;-) > Regarding to the last concern, I have a question: what > business requirements that need the redirect within > a web application? Using the redirect across web > applications or web sites is reasonable as well as when > we dynamically build hyper links. > > A delay at client side? Any more ideas? When you forward request the client URL does not change. This can cause situations where the URL displayed in the browser is inconsistent with what's displayed on the screen. It's useful to do a redirect at the end of some requests in order to reconcile the URL with the page that's displayed. For example, if my login form submits to /processLogin.do and then forwards to my home page, the browser URL will still display /processLogin.do. What I really want is for the browser to display the URL of my home page (say /index.do). So I issue a redirect, rather than forward to achieve this. So what? Well, for one thing, different URLs for the same page can confuse the user. Secondly, if the action was a long running one or updates the database and the user refereshes the screen after a forward it could cause the action to be re-run. I know, you can use tokens to prevent this, but then you get a situation where the user just wants to refresh the home page and ends up getting an error message that a form was submitted out of sequence! So, sometimes a redirect is the right thing to do, but for maximum flexibility it should be done using an ActionFoward with redirect set to true. Steve > > Jing > Netspread Carrier > http://www.netspread.com > > ----- Original Message ----- > From: "Mike Duffy" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, June 28, 2003 11:27 AM > Subject: Sending a Redirect Directly from an Action Class > > > > What are your thoughts on sending a redirect directly from an Action > > class: > > > > response.sendRedirect("/somePage.jsp?"); > > return null; > > > > There is a setRedirect(boolean redirect) in the ActionForward class > > that could be used for the same purpose (with a few extra lines of > > code and an entry in the strutsconfig.xml). > > > > Thanks. > > > > Mike > > > > > > __________________________________ > > Do you Yahoo!? > > SBC Yahoo! DSL - Now only $29.95 per month! > > http://sbc.yahoo.com > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]