請留心asp:Image控件中的ImageUrl屬性

　　建站學院（LieHuo.Net）轉載 今天快下班的時候，打開自己做的頁面，在頁面上（用的是Firefox）隨便點點，檢查看看有沒有什么地方要修改的。但就是這簡單的動作，切發現了一個讓我郁悶的、同時也花了我將近兩個小時才解決的問題----空間首頁發生“二次回調”（感謝網友的指正，本文中所指的二次回調指的是首頁被請求了兩次）了！

　　先說說造成二次請求的元兇：Image控件的ImageUrl屬性！

　　通常，我們都用Image控件來顯示圖片，圖片的路徑就是通過ImageUrl來指定的，這都沒錯，但是，如果用了Image控件，又不給ImageUrl賦值，二次請求的問題就來了。

　　Image控件被服務器解析后，ImageUrl會被轉換成img的src屬性用來標識圖片的路徑，瀏覽器會根據src屬性來請求圖片。當src屬性為空時，瀏覽器會請求當前頁面，這就造成了二次回調。這個回調還是一個標準的PostBack，雖然這個PostBack不影響現有頁面，但是這個PostBack會向服務器再請求一次頁面，必然會給服務器帶來額外的壓力。

　　解決方法：如果使用了Image控件，請務必給ImageUrl賦值！

　　=================================================================
　　感謝木野狐(Neil Chen)對這個問題做出的更加地道的解釋：

　　其中對于木兄說的“并不會帶來什么嚴重后果”，我還是有點疑問：這個原本對圖片的請求被轉移到請求頁面上了，如果被請求頁面的Page_Load事件中有影響性能或功能的代碼，這難道不會給網站的性能和功能帶來影響？

　　問題的根本原因在于，HTML 中 <img /> 如果不設置 src 屬性沒有關系，但是如果設置一個空字符串作為該屬性的值：
　　<img src="" />
　　這時就相當于有了一個默認值為 "./", 也就是對當前目錄下默認文檔的請求。

　　所以，當圖片加載時，會根據 src 指定的值去讀取這個 url 的輸出，這里只是發出了一個 GET 請求，而不是 POST, 所以沒有 Postback 一說。

　　而你恰好測試的是網站首頁，正好是該目錄的默認文檔，所以就被 "./" 這個路徑給引用到了。

　　你可以用一個簡單的 HTML page 來測試，而不用 aspx，就會很明了了。

　　最后的結論是，這個問題不能怨 asp.net，也不能怨 ImageUrl 控件，充其量只能怪它多輸出了一個無用的 url="" 屬性（在沒有指定 ImageUrl 　的情況下），其最壞結果也只是多發出了一次對該目錄下默認文檔的請求而已，并不會帶來什么嚴重后果。

　　=================================================================

　　在下圖，通過分析Request Header中的Accept，不難發現瀏覽器第一次請求服務器時是正常的請求（text/html,application/xhtml+xml），第二次則是在請求圖片（image/png,image/*）：

  　　下面簡單的說說揪出元兇的過程：

　　1.  排除瀏覽器導致二次請求的可能性：由于是在Firefox中發現問題的，于是用IE打開頁面，用HttpAnalyzer監聽發現二次回調還是存在

　　2.  排除MasterPage導致二次請求的可能性：由于頁面用到了MasterPage，打開其他也使用同意個MasterPage的頁面，仔細檢查發現除首頁外，其他頁面不存在二次請求的問題，排除MasterPage出錯的可能性

　　3.  排除Javascript導致二次請求的可能性：在Firebug中，把Javascript禁用后，刷新頁面，發現二次請求還是存在

　　4.  排除后臺代碼導致二次請求的可能性：把后臺代碼全部注釋，刷新頁面，發現二次請求還是存在

　　5.  經過上面的排除法，現在只剩下前臺頁面的造成二次請求的可能性了，雖然頁面代碼不少，但為了解決問題，還是硬著頭皮上：經過漫長的注釋前臺代碼，刷新頁面，功夫不負有心人，終于讓我發現原來是asp:Image造成了二次請求！

　　點擊下載代碼

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈