posted 19 years ago
You need to consider the intent of the two pieces of code.
With forward, the server recieves a request, and then selects and sends a response to the client. This is common in web applications where you need to do things like check users are logged in, validate data and any of a hundred other things before deciding which response to send. For example, you may send a login page if they are not logged in, the previous page if they didn't enter enough data, or the page they actually requested.
With sendRedirect, the client makes a request to the server, and the server does not send a page in response. It sends a message to the client telling them to ask for another page instead. This could be done for a variety of reasons.
One is where the request doesn't have a valid page. I tend to do this on pages that accept HTTP 'POST's. The user posts data, the server processes the data, and then sends the user back to the main menu. This menu is not a view for the processing page! If you treat it as such, then refreshes resubmit the POSTed data rather than just rebuilding the menu!
Another occasion you wouldn't have a display is when you want to track a click in the browser, similar to the scoring on the javablogs site. Even though all blogs are remote (although they don't have to be), when you select a link, it sends a request to their site, their site tracks the request and redirects you to the real destination.
In response to the 'memory consumption', I don't think this is a valid concern - it should (in the grand scheme of things) be negligable, and forward and sendRedirect should be selected on usage and not memory, server load, response time or any other criteria.