Servlet Forwarding and Redirecting

September 18th, 2007
To achieve separation between business logic and presentation in a servlet-based web application, it is generally considered a good idea to have a Servlet that carries out the necessary work and a separate JSP page that will simply display the results. A developer can choose between servlet forwarding or request redirection, based on several criteria.

A request redirection is achieved using the following code from the Servlet:

response.sendRedirect("results-page.jsp");

This will send a 302 Moved Temporarily response to the browser, which will afterwards load the new page with another request. Any data that should be passed from the Servlet to the page should be stored temporarily on the server, in a place that will not be destroyed between the two requests. Such place is the session. Any data should be stored as a session attribute, like this:

request.getSession().setAttribute("mySharedData", mySharedData );

The shared data would then be retrieved from the JSP page using a useBean tag:

<jsp:useBean id="mySharedData" class="..." scope="session"/>

Although this method works, it causes the browser to send a brand new HTTP request for the JSP page. As a result:

  • the URL on the browser's location is changed.

  • reloading current page will reload the JSP page, not the original Servlet.

  • the total loading time will be greater because the browser will have to send two separate HTTP requests.


In addition, shared data will be stored in the session scope, and will be available to all other servlets that will be called within this session, and this may not be what you want.

On the other hand, in some cases it would be more useful to choose forwarding instead of redirecting:

RequestDispatcher dispatcher =
getServletContext().getRequestDispatcher("/results-page.jsp");
dispatcher.forward(request,response);


This will forward the request to the JSP page. The forwarding is performed internally within the servlet container, so no additional HTTP requests are sent by the browser. As a result:

  • the location URL stays unchanged.

  • reloading the page will cause the original servlet to be requested.

  • the page will load faster because there will be only one HTTP request.


Additionally, you don't have to store any shared data in the session any more, as you can simply store them in the request scope. For example, you can store the data from the servlet like this:

request.setAttribute("mySharedData", mySharedData );

And then access them from the JSP page, like this:

<jsp:useBean id="mySharedData" class="..." scope="request"/>

It has to be clear that none of the two methods is better or worse than the other. Sometimes you do want the browser's URL to change. Sometimes you do want the page reload not to cause the original servlet to be executed again (you wouldn't want that when charging a credit card!) Also, some of your data may be necessary to be shared between requests, thus storing them in the session scope is exactly what you should do. The conclusion is, that you have to examine each case, decide which one of the two methods suits best, and use it.

Leave a Reply