sendRedirect Vs requestdispatcher.forward

[Irshad Malek]

tell me the difference between response.sendRedirect and requestDispatcher.forward with respect to session

[Narendra Dhande]

Hi,

When you forward the request with requestDispatcher.forward the target servlet/JSP share the same session. But with sendRedirect the session information is not preserved. ( target is not in scope of session)

Thanks

[Naresh Chaurasia]

hi narendra, does it mean that if for jsp1 i am calling servlet,in the servlet i do sendRedirect to jsp2, then in jsp2 the user will not be able to use the session of jsp1. In other words if user is logged in jsp1, then when he goes to jsp2 he is logged of.Is this what you are trying to say!!!

[Satish Chilukuri]

A RequestDispatcher forward is a server side activity. So the request and its associated session are available to the forwarded resource.

A sendRedirect sends the mentioned url to the browser and the browser sends a new request to that url. sendRedirect is typically used to forward requests to a different context. It is equivalent to opening a new browser and typing in your url.

[Narendra Dhande]

Hi,

Yes, it is exactly as Satish said.

Thanks

[Vishnu Prakash]

To add what Satish said


You might have a scenario in which you want to redirect the request to a different URL, but still want to use a session. There is a special URL encoding method just for that:

response.encodeRedirectURL("/resourceName");

Remember to include the slash in the method.


[ October 18, 2005: Message edited by: vishnu prakash ]

[Narendra Dhande]

Hi,

I think the different URL in the same ServletContext (application ) only. In Different context you can not share the same session.

Thanks

[Priyank Nautiyal]

Hi All,
I read this comment :
------------------------------------------
When you forward the request with requestDispatcher.forward the target servlet/JSP share the same session. But with sendRedirect the session information is not preserved. ( target is not in scope of session)
------------------------------------------
and tried it out by creating two JSPs:
test.jsp:
<% session.setAttribute("message","Hello");
response.sendRedirect("delete.jsp");
%>

and delete.jsp:
<%=session.getAttribute("message")%>

On running test.jsp the delete.jsp page is being called and i can see the message "Hello" being displayed, which as you can see is being retrived from the session object. So doesn't that prove that even sendRedirect() also preserves the session, even without using encodeURL?

[Narendra Dhande]

Hi,

When you forward the request with requestDispatcher.forward the target servlet/JSP share the same session. But with sendRedirect the session information is not preserved. ( target is not in scope of session)

U read the statement in brackets as ( target may not in scope of session). Usually sendRedirect is used to redirect the response to another resource which is not in the same context (Atleast I am using) . On the other hand forward is used to dispatch the request to another resource in the same context. U can dispatch the request in another context, but not all container support it.

In your examle, it is working perfectly. The first JSP set the attribute in the session and call the sendRedirect on the respons onject. The browser take it as the fresh request, but it from the same client (browser window) and the target JSP is in same context. So the session information is always available and the processing is done in same session. The session is not related to particuler request, but it is for all requests comming from same client to the same context.

Your example is running without encodeURL ( actually encodeRedirectURL) as the Cookies may be enabled and the session is not using URL rewirting, therefore no need to attatch the jsessionid to URL


Hope it help you.

Thanks
[ October 18, 2005: Message edited by: Narendra Dhande ]

[Vishnu Prakash]

Originally posted by Narendra

U can dispatch the request to another context, but not all container support it.

Especially Tomcat doesn't support this.

Originally posted by Narendra

Usually sendRedirect is used to redirect the response to another resource which is not in the same context (Atleast I am using) .

Yes it is correct and working

I created 2 applications(Context) and forwarded the request from one context to another context using

response.sendRedirect("/TestOne/JspOne.jsp");


Code in "JspOne.jsp"
<%= session.getAttribute("message")%>

Here "TestOne" is the context and "JspOne.jsp" is the resource.

As Narendra stated

Originally posted by Narendra

When you forward the request with requestDispatcher.forward the target servlet/JSP share the same session. But with sendRedirect the session information is not preserved. ( target is not in scope of session)

with sendRedirect the session information is not preserved.

When I executed my first application with sendRedirect("/TestOne/JspOne.jsp"); method with the following URL
http://localhost:8080/SessionExample/serone

there was a change in the client browser with the new URL but the expected result was not printed
http://localhost:8080/TestOne/JspOne.jsp

The output that I got was null.

Hence this proves the fact that when we use sendRedirect with different context the session is not preserved. Within same Context we can go for requestDispatch rather than sendRedirect.

[Priyank Nautiyal]

Hi Narendra,
If by "target is not in scope of session" you meant target is in a scope higher than session i.e. context scope then yes i do support your argument.Vishnu's statement: "when we use sendRedirect with different context the session is not preserved",is absolutely right. This is because sessions are not shared across contexts. Though a session may be migrated from one context to another,at a particular instance a session can reside only in one context. So a session in one context is not available in another context.
Also I have used RequestDispatcher to forward a request to another context successfully.The code is given below:

//config is the implicit ServletConfig object
ServletContext sc=config.getServletContext();ServletContext context2=sc.getContext("/anotherContext");
RequestDispatcher rd=context2.getRequestDispatcher("/start.jsp");
rd.forward(request,response);

The first context(application) was named "test" while the second was named "anotherContext", which contains a JSP named start.jsp

[Narendra Dhande]

Hi Priyank,

Can ypu please tell me on which environment, you are getting the conetext of another application. I am trying the same using tomcat 5.5.7 in Windows XP, but the get context returning null.

Thanks

[Priyank Nautiyal]

Hi Narendra,

I used tomcat-5.0.28 and it ran fine. Infact i did the same thing sucessfully on weblogic-8.1.3-SP3 as well.

[Narendra Dhande]

Hi Priyank,

Thanks. I will try the same on some other installation.

[Raj Tanneru]

Hi,

When you say sendRedirect(uri).
1. The response first goes back to browser and again a new request is created for the uri specified.
2. As a result old request attributes and parameters will be lost while creating new request.
3. Since you are anyway creating new request, you can specify uri that is out of the context.
4. As the request is coming from browser this is also called client side call.
5. The session still remains active and accessible if you are in the same context. Only request attributes and parameters are lost from scope.

But when you say forward(uri)

1. The server looks for the uri within the context and sends the final response back to browser.
2. URI lookup happens at the server in this case. Hence it is called server side.

Hope this clarifies.

Raj

[Gijs Sijpesteijn]

Hi Narendra,

You will have to modify your server.xml to enable the getContext(). Inside your <host> elements you will have to create a context element like this:

<context crossContext=true path="/otherContext" />

Good luck.