請慎用Ajax請求來探測不存在的資源

ajax|請求

引

    不知道各位有幾個還記得Apress的《Foundations.of.Ajax》中描述的HEAD請求的pattern？

是的，你可以利用XHR向一個你並不知道在與不在的資源發送請求，從而探測期的存在，做出相應的判斷處理。其實發送任何GET請求也可以，只不過一般認為HEAD請求比較輕量級，比較容易使用而已。

但實際上是這樣子嗎？

案例

    在技術上我是比較激進的一派，還保持著熱血青年的特性。所以，在當時新需求到來時，為了印證新技術的可行性，我冒險採用了XHR的HEAD方式。

    需求是這樣的：

    我們需要及時探知遠程伺服器的狀態，從而做到在伺服器狀態發生變化時（比如，機器剛剛啟動起來），通知用戶端的使用者。

    在以前，這樣的需求你是無法用Web實現的。頂多你用一個Web伺服器上的服務端程式去探知，然後發送給Web用戶端。但是，Ajax的到來讓這個變為可能。通過領會Ajax的思想，我們果斷的設計了一種方案，用JavaScript在用戶端建立了一個應用程式，發送XHR請求來探知遠端伺服器的狀態，完成相應的操作。

    可以說，這樣一個設計深諳Ajax的精髓。XHR的進入，讓傳統的B/S程式有向C/S演變的趨勢。該設計迎合這種趨勢，結合需求，實現了這種功能。

問題

    隨著測試的進行，問題接踵而至。

    其實，在剛開始設計此系統時並不是沒有做探索性研究。由於Ajax本身就是一項新技術，即便是其是新瓶裝舊酒，但由於項目之前沒有採用過，任何人都不會貿然採用。

    不過，由於研究匆忙，測試時並沒有覆蓋到所有的case，導致問題的產生。

    當該設計應用到實際的項目中去後，隨著測試的開展，逐漸發現了問題。

    首先，在mozilla 1.2.1環境下發現該程式毫無相應。主要表現為該程式其他功能都可以運行，唯獨XHR探測遠端資源的功能無法使用。為啥呢？

    經過調查，發現問題是這樣的。

    Mozilla低版本瀏覽器確實支援XHR，而且之前我們也有成功的經驗。可問題是Mozilla低版本瀏覽器對XHR的支援在請求不存在資源時有些特殊，具體表現如下。

       當請求不成功時，mozilla 1.2.1得請求順序如下：

１、READY_STATE_LOADING=1;

２、READY_STATE_LOADING=1;

３、READY_STATE_LOADED=2;

之後就銷聲匿跡了。

相反，我們的程式一直在等待READY_STATE_COMPLETE=4;的狀態，所以程式從此失去相應。

從邏輯上講，我們不可以依賴READY_STATE_LOADED狀態。因為在正常時，READY_STATE_LOADED也是有可能出現的。所以，對Mozilla低版本瀏覽器中所存在的這種問題，我們沒有太好的辦法，唯一的辦法就是自己設定逾時機制。

之後，隨著測試的深入，又發現了問題。

僅僅以firefox 1.5.0.4為例來講，其用XHR探測遠端不存在資源的流程也是不一樣的。我們發現，win下的firefox工作正常，而linux下的firefox工作起來非常緩慢。經過測試，我們發現在linux下的firefox環境中，如果要向一個遠端不存在資源發送一個請求，其大約要400秒左右才會有返回，而同樣的操作在win版的firefox上卻只要幾十秒而已。

僅僅時間上長短的不同，就讓我們的應用方案面目皆非。

如果說mozilla低版本瀏覽器由於時間較早，其錯誤處理流程有問題還情有可原。但是，同樣版本的firefox在不同的平台下表現迥異就讓人太不理解了。不過沒辦法，項目要求必須相容不同平台的瀏覽器，也必須相容mozilla，所以。。。。。。

順帶替一句，IE的XHR無論何種操作均表現正常，可以依賴。而開源新貴seamonkey的表現同他的老大哥firefox一樣，平台差異很大。

當然，有些程式只要求在某某平台，某某瀏覽器上實現，那另說。

總結

    第一個吃螃蟹的總是會面臨風險。成功了，人人歌頌；失敗了，儘管沮喪，但是我們也不能放棄一次學習的機會。

    總結如下：

依賴於不變的因素，切莫依賴於變化。在進行OOD時，我們通常會談到兩個原則，即開閉原則和Liskov原則。其實這兩個原則結合起來，就是強調，要面向介面變成。因為介面一般來說都是不變的，而內部的實現是經常變化的。在這裡，我們雖然不是OOD，但是也有一些變與不變的因素。一般來講，人們在實現一個通用的功能時，都會將成功的一面做的特別好，比較一致，而將錯誤處理個人化起來，特別是一個新生事物，成功的一面通過大家的使用，都會統一起來，而錯誤處理由於較少有人碰到，結果導致形態各異。在具體進行設計時，一定要對以來的條件因素進行區分，慎選。如果依賴於一些變化快速的因素，將導致設計失敗。特別考慮那些易變的部分，比如錯誤處理，在前期研究時就要投入更多精力。前期研究時，也應當特別考慮極端情況，從而提高研究的價值，降低風險。