Forward 与 Redirect 两种方式对比

对这两种方式总是忘了看, 看了忘,  索性写成贴子.

效率:
Forward高,  Redirect低, 因为Redirect的流程是这样的,  request 1  sent to server,  server return back to client,  request 2 then sent to server. But Forward 仅在server side处理, 对client side 是透明的. 由于Redirect 有两次传输, 所以效率低.

范围:
由于对request.setAttribute() 来说, 它携带的对象生存范围只在request内, 所以Redirect方式会导致request携带的对象丢失.

总结:  一般还是用Forward比较合适.

forward只能是在相同的context中才行,但redirect就不一定啦.
当然如果可以的话尽可能得用forward.
forward是不用再经过filter的,forward是可以访问到受保护资源的(在WEB-INF目录下的资源).
用forward安全性会更高一点(不过新增的时候刷新就会有点麻烦啦,不知道各位高手有什么好办法呢??).

如果用forward,

浏览器 --> url1 --> url2  --
....^................................|
客户端 <-|->服务端

客户端就不知道返回的结果页的真正URL了,这对那些需要URL2的场合有影响.

xiaoyu能说详细点吗？听得好晕啊！

喔.真是不好意思,我的笔是不太行(表达能力).
forward是不能夸context转发的(例如:/context1/url 的不能用forward 转发到 /context2/url 中去),但是redirect就可以(因为它是浏览器端转发的,是服务器端发送一个http头部信息,浏览器根据这个信息再进行转发,但有一些情况要注意,例如是不同的端口号或者ip的url话,请用绝对url,不要用相对的,否则会出问题,自己想想吧).

如果是用forward转发的话,因为是内部(容器中)转发的,所以也就不用再经过过滤器(filter)的过滤了(如果要是再经过,可能会造成无限递归),但是redirect就要(因为它是多次向服务器请求).

在平时的时候,我们是不可以直接用url来访问WEB-INF目录下的资源的,但是用forward就可以访问得到或者用其它的办法(只要是在服务器执行就应该行了吧).

因为由于forward会屏蔽转发的url,所以呢,当你刷新时还是向原来的Url进行请求,所以要是insert数据的话,那就是insert again.

不知道这样子清楚了点吗??
其实上面是我个人的看法(有一些我都不太敢肯定)

希望大家指教..

拿系统登录举个例子，这里用了Struts。
用户在login.jsp输入用户名、密码，提交到login.do，由类LoginAction响应登录请求，LoginAction验证用户密码正确以后，要将控制转向showMainPageUI.do(或者mainpage.jsp)，这时要用redirect还是forward呢？
当然是redirect！为什么呢？考虑一下showMainPageUI.do这个Action的职责，显而易见是要显示主页面，这和登录的动作有什么关系？没什么关系！我们把登录和显示主页面设计成两个相对独立的用户交互过程，将他们解耦，这有利于各自的重用－－showMainPageUI.do不一定从登录转过来，可以从任意一个请求转过来。
如果用forward的话，有两个害处，1，用户在主页面选择刷新的话，会重新触发登录的动作，这对于系统增加了不必要的负担，2，由于forward允许传递request参数，程序员可能会利用这个特性在login.do和showMainPageUI.do之间传递其它参数，这将产生不必要的耦合，在其它请求转入showMainPageUI.do的时候，如果没有传递那些参数的话，可能会导致失败。
不要陷入技术细节的纠缠，学会关注语义，很多问题都会迎刃而解。

我倒不觉得楼上的就是很好的方法( 我不是很清楚struts是怎么样处理的,但我想它应该是用forward多于redirect ,因为我们经常要传一些必要的bean或者其它的信息给页面(如果不是放到request里,难道会放在session吗??如果是redirect的话,它能用得到request吗??显然不能),再说struts吧,它都不知道我们页面要不要参数,所以它一般都会用forward,其实forward也是转发器默认的方法.).

再说登录吧,首先用redirect会暴露你登录后的页面(安全方面不足).其次如果这个页面要是要经过filter的话(我想一般都会经过filter过滤吧),我想就算是刷新这个redirect也比原来的(用forward)效率好不了多少(一个虽然是要再次提交,但是你这个却要再次过滤).

页面是显示数据的地方,我想解耦(参数与页面)是不太可能的,除非你是一个纯静态的页面(要不你就在页面中执行一些业务行为,但是一般业务行为都很有可能会返回结果).

其实页面与参数的解耦不是用forward与redirect来决定的,因为这两个根本上就与这个解耦搭不上边.



关于刷新这个问题,的确不好解决,但这也是新增的情况才会有的情况(更新话,有版本控制).

请楼上的多多指教..

呃，大家讨论了这么多，不知道考虑过服务器的具体实现没有，对于websphere来说，对于redirect的处理好像有点问题的，如果你不喜欢将上下文名写死的话

不错，大多数情况下我们还是在用forward方式，但是仍然需要有一个原则去指导我们什么时候用forward，什么时候用redirect，对于这个问题，我的看法就是如果两个处理单元（Servlet/JSP/Struts Action）没有必然的联系，就要用redirect，否则用forward。那么是什么决定了处理单元之间的关系？当然是用例中的需求。所以考虑此类问题的时候，出发点是需求，而不是参数传递、性能等技术因素。
我想不出让用户看到redirect后的地址会产生什么样的安全问题。
用不用filter，和上面讨论的问题没有什么关系。
前面讲的解耦，是我没说清楚，真正要表达的意思是“避免产生耦合的可能”，这样就比较明白了吧？
不知道你说的“新增才有的问题”是什么意思。

redirect  可以跨页面访问，而forward, 得根据上下文环境

量体裁衣，我更多的时候选择forward