> -----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]
