重定向和重新路由
在深入介紹有關(guān)錯(cuò)誤的內(nèi)容之前，我們有必要來(lái)討論一下有關(guān)一個(gè)在使用 Ajax 時(shí) 并不需要 關(guān)心的問(wèn)題 —— 重定向。在 HTTP 狀態(tài)代碼中，這是 300 系列的狀態(tài)代碼，包括：
·301：永久移動(dòng)
·302：找到（請(qǐng)求被重新定向到另外一個(gè) URL/URI 上）
·305：使用代理（請(qǐng)求必須使用一個(gè)代理來(lái)訪問(wèn)所請(qǐng)求的資源）
Ajax 程序員可能并不太關(guān)心有關(guān)重定向的問(wèn)題，這是由于兩方面的原因：
·首先，Ajax 應(yīng)用程序通常都是為一個(gè)特定的服務(wù)器端腳本、servlet 或應(yīng)用程序而編寫(xiě)的。對(duì)于那些您看不到就消失了的組件來(lái)說(shuō)，Ajax 程序員就不太清楚了。因此有時(shí)您會(huì)知道資源已經(jīng)移動(dòng)了（因?yàn)槟苿?dòng)了它，或者通過(guò)某種手段移動(dòng)了它），接下來(lái)要修改請(qǐng)求中的 URL，并且不會(huì)再碰到這種結(jié)果了。
更為重要的一個(gè)原因是：Ajax 應(yīng)用程序和請(qǐng)求都是封裝在沙盒中的。這就意味著提供生成 Ajax 請(qǐng)求的 Web 頁(yè)面的域必須是對(duì)這些請(qǐng)求進(jìn)行響應(yīng)的域。因此 ebay.com 所提供的 Web 頁(yè)面就不能對(duì)一個(gè)在 amazon.com 上運(yùn)行的腳本生成一個(gè) Ajax 風(fēng)格的請(qǐng)求；在 ibm.com 上的 Ajax 應(yīng)用程序也無(wú)法對(duì)在 netbeans.org 上運(yùn)行的 servlets 發(fā)出請(qǐng)求。
·結(jié)果是您的請(qǐng)求無(wú)法重定向到其他服務(wù)器上，而不會(huì)產(chǎn)生安全性錯(cuò)誤。在這些情況中，您根本就不會(huì)得到狀態(tài)代碼。通常在調(diào)試控制臺(tái)中都會(huì)產(chǎn)生一個(gè) JavaScript 錯(cuò)誤。因此，在對(duì)狀態(tài)代碼進(jìn)行充分的考慮之后，您就可以完全忽略重定向代碼的問(wèn)題了。
結(jié)果是您的請(qǐng)求無(wú)法重定向到其他服務(wù)器上，而不會(huì)產(chǎn)生安全性錯(cuò)誤。在這些情況中，您根本就不會(huì)得到狀態(tài)代碼。通常在調(diào)試控制臺(tái)中都會(huì)產(chǎn)生一個(gè) JavaScript 錯(cuò)誤。因此，在對(duì)狀態(tài)代碼進(jìn)行充分的考慮之后，您就可以完全忽略重定向代碼的問(wèn)題了。
錯(cuò)誤
一旦接收到狀態(tài)代碼 200 并且意識(shí)到可以很大程度上忽略 300 系列的狀態(tài)代碼之后，所需要擔(dān)心的唯一一組代碼就是 400 系列的代碼了，這說(shuō)明了不同類(lèi)型的錯(cuò)誤?；仡^再來(lái)看一下 清單 7，并注意在對(duì)錯(cuò)誤進(jìn)行處理時(shí)，只將少數(shù)常見(jiàn)的錯(cuò)誤消息輸出給用戶(hù)了。盡管這是朝正確方向前進(jìn)的一步，但是要告訴從事應(yīng)用程序開(kāi)發(fā)的用戶(hù)和程序員究竟發(fā)生了什么問(wèn)題，這些消息仍然是沒(méi)有太大用處的。
首先，我們要添加對(duì)找不到的頁(yè)的支持。實(shí)際上這在大部分產(chǎn)品系統(tǒng)中都不應(yīng)該出現(xiàn)，但是在測(cè)試腳本位置發(fā)生變化或程序員輸入了錯(cuò)誤的 URL 時(shí)，這種情況并不罕見(jiàn)。如果您可以自然地報(bào)告 404 錯(cuò)誤，就可以為那些困擾不堪的用戶(hù)和程序員提供更多幫助。例如，如果服務(wù)器上的一個(gè)腳本被刪除了，我們就可以使用清單 7 中的代碼，這樣用戶(hù)就會(huì)看到一個(gè)如 圖 5 所示的非描述性錯(cuò)誤。
邊界情況和困難情況
圖 5. 常見(jiàn)錯(cuò)誤處理
用戶(hù)無(wú)法判斷問(wèn)題究竟是認(rèn)證問(wèn)題、沒(méi)找到腳本（此處就是這種情況）、用戶(hù)錯(cuò)誤還是代碼中有些地方產(chǎn)生了問(wèn)題。添加一些簡(jiǎn)單的代碼可以讓這個(gè)錯(cuò)誤更加具體。請(qǐng)參照清單 8，它負(fù)責(zé)處理沒(méi)找到的腳本或認(rèn)證發(fā)生錯(cuò)誤的情況，在出現(xiàn)這些錯(cuò)誤時(shí)都會(huì)給出具體的消息。
清單 8. 檢查有效狀態(tài)代碼
雖然這依然相當(dāng)簡(jiǎn)單，但是它的確多提供了一些有用的信息。圖 6 給出了與 圖 5 相同的錯(cuò)誤，但是這一次錯(cuò)誤處理代碼向用戶(hù)或程序員更好地說(shuō)明了究竟發(fā)生了什么。
圖 6. 特殊錯(cuò)誤處理
在我們自己的應(yīng)用程序中，可以考慮在發(fā)生認(rèn)證失敗的情況時(shí)清除用戶(hù)名和密碼，并向屏幕上添加一條錯(cuò)誤消息。我們可以使用類(lèi)似的方法來(lái)更好地處理找不到腳本或其他 400 類(lèi)型的錯(cuò)誤（例如 405 表示不允許使用諸如發(fā)送 HEAD 請(qǐng)求之類(lèi)不可接受的請(qǐng)求方法，而 407 則表示需要進(jìn)行代理認(rèn)證）。然而不管采用哪種選擇，都需要從對(duì)服務(wù)器上返回的狀態(tài)代碼開(kāi)始入手進(jìn)行處理。
其他請(qǐng)求類(lèi)型
如果您真希望控制 XMLHttpRequest 對(duì)象，可以考慮最后實(shí)現(xiàn)這種功能 —— 將 HEAD 請(qǐng)求添加到指令中。在前兩篇文章中，我們已經(jīng)介紹了如何生成 GET 請(qǐng)求；在馬上就要發(fā)表的一篇文章中，您會(huì)學(xué)習(xí)有關(guān)使用 POST 請(qǐng)求將數(shù)據(jù)發(fā)送到服務(wù)器上的知識(shí)。不過(guò)本著增強(qiáng)錯(cuò)誤處理和信息搜集的精神，您應(yīng)該學(xué)習(xí)如何生成 HEAD 請(qǐng)求。
生成請(qǐng)求
實(shí)際上生成 HEAD 請(qǐng)求非常簡(jiǎn)單；您可以使用 "HEAD"（而不是 "GET" 或 "POST"）作為第一個(gè)參數(shù)來(lái)調(diào)用 open() 方法，如 清單 9 所示。
清單 9. 使用 Ajax 生成一個(gè) HEAD 請(qǐng)求
當(dāng)您這樣生成一個(gè) HEAD 請(qǐng)求時(shí)，服務(wù)器并不會(huì)像對(duì) GET 或 POST 請(qǐng)求一樣返回一個(gè)真正的響應(yīng)。相反，服務(wù)器只會(huì)返回資源的頭（header），這包括響應(yīng)中內(nèi)容最后修改的時(shí)間、請(qǐng)求資源是否存在和很多其他有用信息。您可以在服務(wù)器處理并返回資源之前使用這些信息來(lái)了解有關(guān)資源的信息。
對(duì)于這種請(qǐng)求您可以做的最簡(jiǎn)單的事情就是簡(jiǎn)單地輸出所有的響應(yīng)頭的內(nèi)容。這可以讓您了解通過(guò) HEAD 請(qǐng)求可以使用什么。清單 10 提供了一個(gè)簡(jiǎn)單的回調(diào)函數(shù)，用來(lái)輸出從 HEAD 請(qǐng)求中獲得的響應(yīng)頭的內(nèi)容。
清單 10. 輸出從 HEAD 請(qǐng)求中獲得的響應(yīng)頭的內(nèi)容
請(qǐng)參見(jiàn) 圖 7，其中顯示了從一個(gè)向服務(wù)器發(fā)出的 HEAD 請(qǐng)求的簡(jiǎn)單 Ajax 應(yīng)用程序返回的響應(yīng)頭。
您可以單獨(dú)使用這些頭（從服務(wù)器類(lèi)型到內(nèi)容類(lèi)型）在 Ajax 應(yīng)用程序中提供其他信息或功能。
檢查 URL
您已經(jīng)看到了當(dāng) URL 不存在時(shí)應(yīng)該如何檢查 404 錯(cuò)誤。如果這變成一個(gè)常見(jiàn)的問(wèn)題 —— 可能是缺少了一個(gè)特定的腳本或 servlet —— 那么您就可能會(huì)希望在生成完整的 GET 或 POST 請(qǐng)求之前來(lái)檢查這個(gè) URL。要實(shí)現(xiàn)這種功能，生成一個(gè) HEAD 請(qǐng)求，然后在回調(diào)函數(shù)中檢查 404 錯(cuò)誤；清單 11 給出了一個(gè)簡(jiǎn)單的回調(diào)函數(shù)。
清單 11. 檢查某個(gè) URL 是否存在
誠(chéng)實(shí)地說(shuō)，這段代碼的價(jià)值并不太大。服務(wù)器必須對(duì)請(qǐng)求進(jìn)行響應(yīng)，并構(gòu)造一個(gè)響應(yīng)來(lái)填充內(nèi)容長(zhǎng)度的響應(yīng)頭，因此并不能節(jié)省任何處理時(shí)間。另外，這花費(fèi)的時(shí)間與生成請(qǐng)求并使用 HEAD 請(qǐng)求來(lái)查看 URL 是否存在所需要的時(shí)間一樣多，因?yàn)樗墒褂?GET 或 POST 的請(qǐng)求，而不僅僅是如 清單 7 所示一樣來(lái)處理錯(cuò)誤代碼。不過(guò)，有時(shí)確切地了解目前什么可用也是非常有用的；您永遠(yuǎn)不會(huì)知道何時(shí)創(chuàng)造力就會(huì)迸發(fā)或者何時(shí)需要 HEAD 請(qǐng)求！
有用的 HEAD 請(qǐng)求
您會(huì)發(fā)現(xiàn) HEAD 請(qǐng)求非常有用的一個(gè)領(lǐng)域是用來(lái)查看內(nèi)容的長(zhǎng)度或內(nèi)容的類(lèi)型。這樣可以確定是否需要發(fā)回大量數(shù)據(jù)來(lái)處理請(qǐng)求，和服務(wù)器是否試圖返回二進(jìn)制數(shù)據(jù)，而不是 HTML、文本或 XML（在 JavaScript 中，這 3 種類(lèi)型的數(shù)據(jù)都比二進(jìn)制數(shù)據(jù)更容易處理）。
在這些情況中，您只使用了適當(dāng)?shù)念^名，并將其傳遞給 XMLHttpRequest 對(duì)象的 getResponseHeader() 方法。因此要獲取響應(yīng)的長(zhǎng)度，只需要調(diào)用 request.getResponseHeader("Content-Length");。要獲取內(nèi)容類(lèi)型，請(qǐng)使用 request.getResponseHeader("Content-Type");。
在很多應(yīng)用程序中，生成 HEAD 請(qǐng)求并沒(méi)有增加任何功能，甚至可能會(huì)導(dǎo)致請(qǐng)求速度變慢（通過(guò)強(qiáng)制生成一個(gè) HEAD 請(qǐng)求來(lái)獲取有關(guān)響應(yīng)的數(shù)據(jù)，然后在使用一個(gè) GET 或 POST 請(qǐng)求來(lái)真正獲取響應(yīng)）。然而，在出現(xiàn)您不確定有關(guān)腳本或服務(wù)器端組件的情況時(shí)，使用 HEAD 請(qǐng)求可以獲取一些基本的數(shù)據(jù)，而不需要對(duì)響應(yīng)數(shù)據(jù)真正進(jìn)行處理，也不需要大量的帶寬來(lái)發(fā)送響應(yīng)。
結(jié)束語(yǔ)
對(duì)于很多 Ajax 和 Web 程序員來(lái)說(shuō)，本文中介紹的內(nèi)容似乎是太高級(jí)了。生成 HEAD 請(qǐng)求的價(jià)值是什么呢？到底在什么情況下需要在 JavaScript 中顯式地處理重定向狀態(tài)代碼呢？這些都是很好的問(wèn)題；對(duì)于簡(jiǎn)單的應(yīng)用程序來(lái)說(shuō)，答案是這些高級(jí)技術(shù)的價(jià)值并不是非常大。
然而，Web 已經(jīng)不再是只需實(shí)現(xiàn)簡(jiǎn)單應(yīng)用程序的地方了；用戶(hù)已經(jīng)變得更加高級(jí)，客戶(hù)期望能夠獲得更好的穩(wěn)定性、更高級(jí)的錯(cuò)誤報(bào)告，如果應(yīng)用程序有 1% 的時(shí)間停機(jī)，那么經(jīng)理就可能會(huì)因此而被解雇。
因此您的工作就不能僅僅局限于簡(jiǎn)單的應(yīng)用程序了，而是需要更深入理解 XMLHttpRequest。
·如果您可以考慮各種就緒狀態(tài) —— 并且理解了這些就緒狀態(tài)在不同瀏覽器之間的區(qū)別 —— 就可以快速調(diào)試應(yīng)用程序了。您甚至可以基于就緒狀態(tài)而開(kāi)發(fā)一些創(chuàng)造性的功能，并向用戶(hù)和客戶(hù)回報(bào)請(qǐng)求的狀態(tài)。
·如果您要對(duì)狀態(tài)代碼進(jìn)行控制，就可以設(shè)置應(yīng)用程序來(lái)處理腳本錯(cuò)誤、非預(yù)期的響應(yīng)以及邊緣情況。結(jié)果是應(yīng)用程序在所有的時(shí)間都可以正常工作，而不僅僅是只能一切都正常的情況下才能運(yùn)行。
·增加這種生成 HEAD 請(qǐng)求的能力，檢查某個(gè) URL 是否存在，以及確認(rèn)某個(gè)文件是否被修改過(guò)，這樣就可以確保用戶(hù)可以獲得有效的頁(yè)面，用戶(hù)所看到的信息都是最新的，（最重要的是）讓他們驚訝這個(gè)應(yīng)用程序是如何健壯和通用。
本文的目的并非是要讓您的應(yīng)用程序顯得十分華麗，而是幫助您去掉黃色聚光燈后重點(diǎn)昭顯文字的美麗，或者外觀更像桌面一樣。盡管這些都是 Ajax 的功能（在后續(xù)幾篇文章中就會(huì)介紹），不過(guò)它們卻像是蛋糕表面的一層奶油。如果您可以使用 Ajax 來(lái)構(gòu)建一個(gè)堅(jiān)實(shí)的基礎(chǔ)，讓?xiě)?yīng)用程序可以很好地處理錯(cuò)誤和問(wèn)題，用戶(hù)就會(huì)返回您的站點(diǎn)和應(yīng)用程序。在接下來(lái)的文章中，我們將添加這種直觀的技巧，這會(huì)讓客戶(hù)興奮得發(fā)抖。（認(rèn)真地說(shuō)，您一定不希望錯(cuò)過(guò)下一篇文章?。?/p>
出處：IBM developerWorks
責(zé)任編輯：moby
看到現(xiàn)在，一些新手程序員就可能會(huì)這究竟是要討論什么內(nèi)容。有一點(diǎn)事實(shí)大家需要知道：只有不到 5% 的 Ajax 請(qǐng)求需要使用諸如 2、3 之類(lèi)的就緒狀態(tài)和諸如 403 之類(lèi)的狀態(tài)代碼（實(shí)際上，這個(gè)比率可能更接近于 1% 甚至更少）。這些情況非常重要，稱(chēng)為 邊界情況（edge case） —— 它們只會(huì)在一些非常特殊的情況下發(fā)生，其中遇到的都是最奇特的問(wèn)題。雖然這些情況并不普遍，但是這些邊界情況卻占據(jù)了大部分用戶(hù)所碰到的問(wèn)題的 80%!
對(duì)于典型的用戶(hù)來(lái)說(shuō)，應(yīng)用程序 100 次都是正常工作的這個(gè)事實(shí)通常都會(huì)被忘記，然而應(yīng)用程序只要一次出錯(cuò)就會(huì)被他們清楚地記住。如果您可以很好地處理邊界情況（或困難情況），就可以為再次訪問(wèn)站點(diǎn)的用戶(hù)提供滿(mǎn)意的回報(bào)。
在多個(gè) JavaScript 函數(shù)都使用相同的請(qǐng)求對(duì)象時(shí)，您需要檢查就緒狀態(tài) 0 來(lái)確保這個(gè)請(qǐng)求對(duì)象沒(méi)有正在使用，這種機(jī)制會(huì)產(chǎn)生問(wèn)題。由于 readyState == 4 表示一個(gè)已完成的請(qǐng)求，因此您經(jīng)常會(huì)發(fā)現(xiàn)那些目前沒(méi)在使用的處于就緒狀態(tài)的請(qǐng)求對(duì)象仍然被設(shè)置成了 4 —— 這是因?yàn)閺姆?wù)器返回來(lái)的數(shù)據(jù)已經(jīng)使用過(guò)了，但是從它們被設(shè)置為就緒狀態(tài)之后就沒(méi)有進(jìn)行任何變化。有一個(gè)函數(shù) abort() 會(huì)重新設(shè)置請(qǐng)求對(duì)象，但是這個(gè)函數(shù)卻不是真正為了這個(gè)目的而使用的。如果您必須使用多個(gè)函數(shù)，最好是為每個(gè)函數(shù)都創(chuàng)建并使用一個(gè)函數(shù)，而不是在多個(gè)函數(shù)之間共享相同的對(duì)象。
XMLHttpRequest 或 XMLHttp：換名玫瑰
Microsoft" 和 Internet Explorer 使用了一個(gè)名為 XMLHttp 的對(duì)象，而不是 XMLHttpRequest 對(duì)象，而 Mozilla、Opera、Safari 和 大部分非 Microsoft 瀏覽器都使用的是后者。為了簡(jiǎn)單性起見(jiàn)，我將這兩個(gè)對(duì)象都簡(jiǎn)單地稱(chēng)為 XMLHttpRequest。這既符合我們?cè)?Web 上看到的情況，又符合 Microsoft 在 Internet Explorer 7.0 中使用 XMLHttpRequest 作為請(qǐng)求對(duì)象的意圖。（有關(guān)這個(gè)問(wèn)題的更多內(nèi)容，請(qǐng)參見(jiàn) 第 2 部分。）
聯(lián)系客服
