response.sendRedirect(URL) Vs. RequestDispatcher

[Fran Varin]

In a recent discussion with a coworker a point was made regarding the difference between response.sendRedirect(URL) and RequestDispatcher.forward(). As I understand the essential difference is that the sendRedirect is actually sent directly to the browser. The browser then innitiates a new request from the server for the JSP. The results in a network hop to have the request issued and elimiates the use of the HTTP Request and Response objects from the JSP since they no longer have addressability to them. Contrasted, with the RequestDispatcher.forward where the transfer of control from a servlet to a JSP happens on the server and all resources are available to the target JSP. A post form "The Serverside" seems to indicate an interesting behavior that I'm having a hard time accepting since disptatch.forward is so widely used. In his post, Paul Strack says the following:

"1) If you use a RequestDispatcher, the target servlet/JSP receives the same request/response objects as the original servlet/JSP. Therefore, you can pass data between them using request.setAttribute(). With a sendRedirect(), it is a new request from the client, and the only way to pass data is through the session or with web parameters (url?name=value).

2) A sendRedirect() also updates the browser history. Suppose you have JSP-1 which has a form that targets Servlet-2, which then redirects to JSP-3. With a redirect, the user's address bar will read "http://[host]/JSP-3". If the user clicks the Reload/Refresh button, only JSP-3 will be re-executed, not Servlet-2.

If you use a RequestDispatcher to forward from Servlet-2 to JSP-3, the user's address bar will read "http://[host]/Servlet-2". A reload/refresh will execute both Servlet-2 and JSP-3. This can be important if Servlet-2 performs some system update (such as credit-card processing)."


My issue comes with understanding exactly what Mr. Strack is really saying. It does not seem reasonable that the Servlet would be executed as well as the JSP upon a reload/refresh. Especially, in light of the original HTTP Request and Response no longer being available. Could someone either validate his assertion or provide a clearer explanation?


Here is the url to the post on "The Serverside"

http://www.theserverside.com/discussions/thread.tss?thread_id=26425#124872124872



Thanks so much for the insight!
Fran Varin

[David O'Meara]

When you refresh you are resending the previous request. In the case of a 'forward', it is the same rquest to the servlet and then the JSP, both get hit. In the case of a sendRedirect, the 'previous request' is the second one ie the address specified in the sendRedirect() and not the one before that.

Does this make it any clearer?

[Fran Varin]

Since the behavior is different I am struggling with why there are two approaches then. If the behavior was identical then dispatch.forward would clearly represent an advantage in performance and flexibility when access to server based data (i.e. beans bound to the request) is desired. In that scenario, sendRedirect would be appropriate to point a browser at a different site altogether. This idea has been my general understanding for some time.

So, if disptach.forward is handled so differently then, how can applications and even frameworks rely on it for error free transfers of control between servlets and JSPs? Why use it at all? In the case of a sensitive transaction perhaps a credit card transaction as Mr. Strack points out, how can we ensure that we do not receive duplicate payment?

Please understand, I'm not being argumentative. I'm just searching for a clear understanding on this point. It seems that disptach.forward is a fundamental function within java and to see such a behavior is surprising.

Fran

[David O'Meara]

I'll gfive you a light introduction to the way I usualy do things, others here use a similar method and may flesh out the light details I give.

Firstly, forward is used to support the MVC architecture, so the servlet manages the control, sets the data and forwards to the JSP for display. The JSP handles display only. If the user refershes the page, they get the data loaded again, no problems.

The user enters their data and submits (HTTP POST) to the processing form. This Servlet does all the work, and you don't want it being called again. That would be bad. After processing you use sendRedirect to return a confirmation notice. If the user reloads the page, they get the confirmation notice.

The difference is subtle, but you cannot substitute one fr the other here.