先前看了一本書後發現原來Response.Redirect的動作總共要client與server端來回2次
Response.Redirect它的動作像是這樣的:
client像server端要求Response.Redirect("新網址")
然後server端告訴我們的瀏覽器要轉到"新網址"
先前看了一本書後發現原來Response.Redirect的動作總共要client與server端來回2次
Response.Redirect它的動作像是這樣的:
client像server端要求Response.Redirect("新網址")
然後server端告訴我們的瀏覽器要轉到"新網址"
client再跟serverv端要求"新網址"的回應
server端再將"新網址"的內容傳送給我們
很肉肉長對不對?
然後書上說
Server.Transfer可以減少一次往返
也就是它的動作是:
client跟server端要求Server.Transfer("新網址")
server端直接做好轉址的動作並將新網址的內容傳送給我們
(但是瀏覽器並不知道已經轉址了)
看了很心動對不對?
簡簡單單換個寫法差那麼多而且又對資料往返有幫助誰不想換阿
於是cloudio就很開心的都將Response.Redirect改寫成Server.Transfer
結果有一次cloudio在一支維護資料的程式中的送出新資料並轉址到資料的清單頁面事件中使用了Server.Transfer
然後再轉址後的清單頁面發生了一件事
就是只要我每reload頁面一次
畫面上就跳出一次"您已成功更新一筆資料"....真的是看傻眼了
到這邊應該就會發現是轉址的問題
然後測試了幾次後發現
原來Server.Transfer並不是完完整整的把你帶到你要求轉址的新頁面
他的動作是server端已經傳送的header與Page.Load以前的事件會保留住而不會消失
而包含Server.Transfer的事件也不會消失
現在我們仔細看看我們的網址列會發現我們還停留在轉址前的那個頁面
我們知道ASP.NET輸出頁面的事件的順序是
Page.PreInit
Page.Init
Page.InitComplete
Page.PreLoad
Page.Load
Page.LoadComplete
Page.PreRender
Page.PreRenderComplete
也就是說Page.Load前會觸發的事件只要有寫程式而沒有被包在!this.IsPostBack的話
就出現事件中的code不斷的因為reload而被執行
今天好加在cloudio有在更新完資料後先alert一段文字
才會在清單頁面每次reload就alert一次來提醒我讓我發現這個問題
如果今天cloudio沒有做alert的動作而這支要轉址到其他頁面的程式是刪除資料的程式呢?
後果應該會不堪設想吧...
因為看了F6 Team大大的文章
然後又上網查了一下發現大家都沒提到這個問題
都是只提到Server.Transfer比較好的比較多
所以提出cloudio碰到過的問題來分享
附上一些參考的程式給大家跑看看