今天在做一个Web项目的最后部署工作的时候产生了一个问题,经过多次的试验,得出问题的关键就是出现在重定向方法的使用上,从而对这个问题进行了一下深入的研究。得出的结论应该已经有人说明过,我只是从应用的角度再来说明一下问题。呵呵,有点献丑的感觉。
问题的产生:
在这个Web项目的部署时,做了一个Frame,顶端是top,下边左边是menu,右边是main,工作区。此时,这个包含frame的页面是部署在A服务器上。
因为实际情况决定,通过menu的一个节点,在工作区请求了部署在B服务器上的一个页面(暂时叫做B1页面),这个B1页面是部署在B服务器上的一个查询系统的初始页面。在程序设计时,通过B1页面的一些选择,得到了一些条件,赋值给Session,然后重定向到结果页面B2,使用的方法是:Response.Redirect。在B2页面中,获得此Session,然后进行条件组合,得到结果列表。
问题就产生在由B1页面重定向到B2时,在B2页面中启动了报错机制,得出的结果是B2页面的Session为null值,所以报错。
此时的问题是:B服务器上的B1页面由A服务器上的menu页面请求获得,并仍然显示在A服务器Frame的工作区内,但B服务器上的B2页面无法获得B1页面形成的Session。
但是,当在A服务器上的menu页面上,新开一个窗口请求B1页面,然后形成Session,再重定向至B2页面,就没有此问题,B2页面能获得Session并列出结果。而且,在回到A服务器的Frame中请求B1页面,显示在A服务器Frame的工作区内B1到B2页面也是一切正常。
分析的结果就是,但在A服务器的Frame内请求时,B1页面形成的Session是存在于A服务器上,所以B2页面无法在B服务器上获得Session。而新开一个窗口请求B1页面,相当于在B服务器上来一个新的请求,所以B1页面形成的Session就存在于B服务器上,可以正常使用,而此时再返回在A服务器的Frame内请求时,因为B服务器上已经存在Session,所以此时在A服务器的Frame内,B1和B2页面又可以正常工作了。
到现在,问题原因已经分析出来了,但是没有解决问题,因为我要的是直接在A服务器的Frame内请求时就可以得到正确的结果。
因为分析是因为形成Session的位置不对,所以经过和同事的讨论,决定修改重定向方法,不用Response.Redirect,而使用Server.Transfer,结果一下就成功了,即使直接在A服务器的Frame内请求B1页面,也可以正确的在B2页面中得出结果了。此时,就得出了一个问题:Response.Redirect和Server.Transfer在服务器端的数据传输上有什么区别。
和同事讨论,都没有得出个所以然,然后在网上查找。得出的结果是:“雖然Server.Transfer和Response.Redirect都會轉向,但兩者之間仍有些不同:Response.Redirect是先由伺服器端將資料送到用戶端,用戶端再依照Redirect內容,向伺服器端要求轉向到另一個網頁,如此會增加一次用戶端與伺服器端來回通訊時間,而Server.Transfer則是在伺服器端直接轉向到另一個網頁。並且由於Server.Transfer轉向前後的網頁,仍屬同一應用程式,因此會將Session和Application的變數值帶到轉向後的URL位置,而Response.Redirect不會。”具体页面请看这里(微软的解释)。
看完后,我的理解是这样的:使用Response.Redirect方法时重定向操作发生在客户端,总共涉及到两次与服务器的通信,第一次是对原始页面的请求,第二次是声明的新页面,并重定向至新页面;而Server.Transfer方法在同一执行流中,从当前的ASPX文件直接转到同一服务器上的另一个ASPX页面,当前的ASPX页面终止执行,并转入新的ASPX页面,但新的ASPX页面仍使用前一ASPX页面创建的请求。
最后得出的结果就是:在同一个窗口中,请求的是同一台服务器上的页面时,Response.Redirect和Server.Transfer是没有太多的区别的;而在同一个窗口中,请求的是不同服务器上的页面时,为了保证页面的正常执行,推荐使用Server.Transfer这种重定向方法。当然要视具体的应用而定。