掌握AJAX第5/7頁
XMLHttpRequest 對象（2006 年 1 月）。
XMLHttpRequest 實例、構(gòu)造和發(fā)送請求，以及響應(yīng)服務(wù)器（2006 年 2 月）。
XMLHttpRequest 對象的理解（2006 年 3 月）。
它花費了最小的努力來確保服務(wù)器不但完成了一個請求，而且還返回了一個 “一切良好” 的狀態(tài)代碼。這個代碼是 "200"，它是通過 XMLHttpRequest 對象的 status 屬性來報告的。為了確保服務(wù)器不但完成了一個請求，而且還報告了一個 OK 狀態(tài)，請在您的回調(diào)函數(shù)中添加另外一個檢查功能，如 清單 7 所示。
清單 7. 檢查有效狀態(tài)代碼
function updatePage() {
if (request.readyState == 4) {
if (request.status == 200) {
var response = request.responseText.split("|");
document.getElementById("order").value = response[0];
document.getElementById("address").innerHTML =
response[1].replace(/\n/g, "<br />");
} else
alert("status is " + request.status);
}
}
通過添加這幾行代碼，您就可以確認(rèn)是否存在問題，用戶會看到一個有用的錯誤消息，而不僅僅是看到一個由斷章取義的數(shù)據(jù)所構(gòu)成的頁面，而沒有任何解釋。
重定向和重新路由
在深入介紹有關(guān)錯誤的內(nèi)容之前，我們有必要來討論一下有關(guān)一個在使用 Ajax 時 并不需要 關(guān)心的問題 —— 重定向。在 HTTP 狀態(tài)代碼中，這是 300 系列的狀態(tài)代碼，包括：
·301：永久移動
·302：找到（請求被重新定向到另外一個 URL/URI 上）
·305：使用代理（請求必須使用一個代理來訪問所請求的資源）
Ajax 程序員可能并不太關(guān)心有關(guān)重定向的問題，這是由于兩方面的原因：
·首先，Ajax 應(yīng)用程序通常都是為一個特定的服務(wù)器端腳本、servlet 或應(yīng)用程序而編寫的。對于那些您看不到就消失了的組件來說，Ajax 程序員就不太清楚了。因此有時您會知道資源已經(jīng)移動了（因為您移動了它，或者通過某種手段移動了它），接下來要修改請求中的 URL，并且不會再碰到這種結(jié)果了。
更為重要的一個原因是：Ajax 應(yīng)用程序和請求都是封裝在沙盒中的。這就意味著提供生成 Ajax 請求的 Web 頁面的域必須是對這些請求進行響應(yīng)的域。因此 ebay.com 所提供的 Web 頁面就不能對一個在 amazon.com 上運行的腳本生成一個 Ajax 風(fēng)格的請求；在 ibm.com 上的 Ajax 應(yīng)用程序也無法對在 netbeans.org 上運行的 servlets 發(fā)出請求。
·結(jié)果是您的請求無法重定向到其他服務(wù)器上，而不會產(chǎn)生安全性錯誤。在這些情況中，您根本就不會得到狀態(tài)代碼。通常在調(diào)試控制臺中都會產(chǎn)生一個 JavaScript 錯誤。因此，在對狀態(tài)代碼進行充分的考慮之后，您就可以完全忽略重定向代碼的問題了。
結(jié)果是您的請求無法重定向到其他服務(wù)器上，而不會產(chǎn)生安全性錯誤。在這些情況中，您根本就不會得到狀態(tài)代碼。通常在調(diào)試控制臺中都會產(chǎn)生一個 JavaScript 錯誤。因此，在對狀態(tài)代碼進行充分的考慮之后，您就可以完全忽略重定向代碼的問題了。
錯誤
一旦接收到狀態(tài)代碼 200 并且意識到可以很大程度上忽略 300 系列的狀態(tài)代碼之后，所需要擔(dān)心的唯一一組代碼就是 400 系列的代碼了，這說明了不同類型的錯誤?；仡^再來看一下 清單 7，并注意在對錯誤進行處理時，只將少數(shù)常見的錯誤消息輸出給用戶了。盡管這是朝正確方向前進的一步，但是要告訴從事應(yīng)用程序開發(fā)的用戶和程序員究竟發(fā)生了什么問題，這些消息仍然是沒有太大用處的。
首先，我們要添加對找不到的頁的支持。實際上這在大部分產(chǎn)品系統(tǒng)中都不應(yīng)該出現(xiàn)，但是在測試腳本位置發(fā)生變化或程序員輸入了錯誤的 URL 時，這種情況并不罕見。如果您可以自然地報告 404 錯誤，就可以為那些困擾不堪的用戶和程序員提供更多幫助。例如，如果服務(wù)器上的一個腳本被刪除了，我們就可以使用 清單 7 中的代碼，這樣用戶就會看到一個如 圖 5 所示的非描述性錯誤。
邊界情況和困難情況
看到現(xiàn)在，一些新手程序員就可能會這究竟是要討論什么內(nèi)容。有一點事實大家需要知道：只有不到 5% 的 Ajax 請求需要使用諸如 2、3 之類的就緒狀態(tài)和諸如 403 之類的狀態(tài)代碼（實際上，這個比率可能更接近于 1% 甚至更少）。這些情況非常重要，稱為 邊界情況（edge case） —— 它們只會在一些非常特殊的情況下發(fā)生，其中遇到的都是最奇特的問題。雖然這些情況并不普遍，但是這些邊界情況卻占據(jù)了大部分用戶所碰到的問題的 80%!
對于典型的用戶來說，應(yīng)用程序 100 次都是正常工作的這個事實通常都會被忘記，然而應(yīng)用程序只要一次出錯就會被他們清楚地記住。如果您可以很好地處理邊界情況（或困難情況），就可以為再次訪問站點的用戶提供滿意的回報。
圖 5. 常見錯誤處理
用戶無法判斷問題究竟是認(rèn)證問題、沒找到腳本（此處就是這種情況）、用戶錯誤還是代碼中有些地方產(chǎn)生了問題。添加一些簡單的代碼可以讓這個錯誤更加具體。請參照 清單 8，它負(fù)責(zé)處理沒找到的腳本或認(rèn)證發(fā)生錯誤的情況，在出現(xiàn)這些錯誤時都會給出具體的消息。
清單 8. 檢查有效狀態(tài)代碼
function updatePage() {
if (request.readyState == 4) {
if (request.status == 200) {
var response = request.responseText.split("|");
document.getElementById("order").value = response[0];
document.getElementById("address").innerHTML =
response[1].replace(/\n/g, "<br />");
} else if (request.status == 404) {
alert ("Requested URL is not found.");
} else if (request.status == 403) {
alert("Access denied.");
} else
alert("status is " + request.status);
}
}
雖然這依然相當(dāng)簡單，但是它的確多提供了一些有用的信息。圖 6 給出了與 圖 5 相同的錯誤，但是這一次錯誤處理代碼向用戶或程序員更好地說明了究竟發(fā)生了什么。
圖 6. 特殊錯誤處理
在我們自己的應(yīng)用程序中，可以考慮在發(fā)生認(rèn)證失敗的情況時清除用戶名和密碼，并向屏幕上添加一條錯誤消息。我們可以使用類似的方法來更好地處理找不到腳本或其他 400 類型的錯誤（例如 405 表示不允許使用諸如發(fā)送 HEAD 請求之類不可接受的請求方法，而 407 則表示需要進行代理認(rèn)證）。然而不管采用哪種選擇，都需要從對服務(wù)器上返回的狀態(tài)代碼開始入手進行處理。
其他請求類型
如果您真希望控制 XMLHttpRequest 對象，可以考慮最后實現(xiàn)這種功能 —— 將 HEAD 請求添加到指令中。在前兩篇文章中，我們已經(jīng)介紹了如何生成 GET 請求；在馬上就要發(fā)表的一篇文章中，您會學(xué)習(xí)有關(guān)使用 POST 請求將數(shù)據(jù)發(fā)送到服務(wù)器上的知識。不過本著增強錯誤處理和信息搜集的精神，您應(yīng)該學(xué)習(xí)如何生成 HEAD 請求。
生成請求
實際上生成 HEAD 請求非常簡單；您可以使用 "HEAD"（而不是 "GET" 或 "POST"）作為第一個參數(shù)來調(diào)用 open() 方法，如 清單 9 所示。
清單 9. 使用 Ajax 生成一個 HEAD 請求
function getSalesData() {
createRequest();
var url = "/boards/servlet/UpdateBoardSales";
request.open("HEAD", url, true);
request.onreadystatechange = updatePage;
request.send(null);
}
當(dāng)您這樣生成一個 HEAD 請求時，服務(wù)器并不會像對 GET 或 POST 請求一樣返回一個真正的響應(yīng)。相反，服務(wù)器只會返回資源的 頭（header），這包括響應(yīng)中內(nèi)容最后修改的時間、請求資源是否存在和很多其他有用信息。您可以在服務(wù)器處理并返回資源之前使用這些信息來了解有關(guān)資源的信息。
對于這種請求您可以做的最簡單的事情就是簡單地輸出所有的響應(yīng)頭的內(nèi)容。這可以讓您了解通過 HEAD 請求可以使用什么。清單 10 提供了一個簡單的回調(diào)函數(shù)，用來輸出從 HEAD 請求中獲得的響應(yīng)頭的內(nèi)容。
清單 10. 輸出從 HEAD 請求中獲得的響應(yīng)頭的內(nèi)容
function updatePage() {
if (request.readyState == 4) {
alert(request.getAllResponseHeaders());
}
}
請參見 圖 7，其中顯示了從一個向服務(wù)器發(fā)出的 HEAD 請求的簡單 Ajax 應(yīng)用程序返回的響應(yīng)頭。
您可以單獨使用這些頭（從服務(wù)器類型到內(nèi)容類型）在 Ajax 應(yīng)用程序中提供其他信息或功能。
檢查 URL
您已經(jīng)看到了當(dāng) URL 不存在時應(yīng)該如何檢查 404 錯誤。如果這變成一個常見的問題 —— 可能是缺少了一個特定的腳本或 servlet —— 那么您就可能會希望在生成完整的 GET 或 POST 請求之前來檢查這個 URL。要實現(xiàn)這種功能，生成一個 HEAD 請求，然后在回調(diào)函數(shù)中檢查 404 錯誤；清單 11 給出了一個簡單的回調(diào)函數(shù)。
清單 11. 檢查某個 URL 是否存在
function updatePage() {
if (request.readyState == 4) {
if (request.status == 200) {
alert("URL exists");
} else if (request.status == 404) {
alert("URL does not exist.");
} else {
alert("Status is: " + request.status);
}
}
}
誠實地說，這段代碼的價值并不太大。服務(wù)器必須對請求進行響應(yīng)，并構(gòu)造一個響應(yīng)來填充內(nèi)容長度的響應(yīng)頭，因此并不能節(jié)省任何處理時間。另外，這花費的時間與生成請求并使用 HEAD 請求來查看 URL 是否存在所需要的時間一樣多，因為它要生成使用 GET 或 POST 的請求，而不僅僅是如 清單 7 所示一樣來處理錯誤代碼。不過，有時確切地了解目前什么可用也是非常有用的；您永遠不會知道何時創(chuàng)造力就會迸發(fā)或者何時需要 HEAD 請求！
有用的 HEAD 請求
您會發(fā)現(xiàn) HEAD 請求非常有用的一個領(lǐng)域是用來查看內(nèi)容的長度或內(nèi)容的類型。這樣可以確定是否需要發(fā)回大量數(shù)據(jù)來處理請求，和服務(wù)器是否試圖返回二進制數(shù)據(jù)，而不是 HTML、文本或 XML（在 JavaScript 中，這 3 種類型的數(shù)據(jù)都比二進制數(shù)據(jù)更容易處理）。
在這些情況中，您只使用了適當(dāng)?shù)念^名，并將其傳遞給 XMLHttpRequest 對象的 getResponseHeader() 方法。因此要獲取響應(yīng)的長度，只需要調(diào)用 request.getResponseHeader("Content-Length");。要獲取內(nèi)容類型，請使用 request.getResponseHeader("Content-Type");。
在很多應(yīng)用程序中，生成 HEAD 請求并沒有增加任何功能，甚至可能會導(dǎo)致請求速度變慢（通過強制生成一個 HEAD 請求來獲取有關(guān)響應(yīng)的數(shù)據(jù)，然后在使用一個 GET 或 POST 請求來真正獲取響應(yīng)）。然而，在出現(xiàn)您不確定有關(guān)腳本或服務(wù)器端組件的情況時，使用 HEAD 請求可以獲取一些基本的數(shù)據(jù)，而不需要對響應(yīng)數(shù)據(jù)真正進行處理，也不需要大量的帶寬來發(fā)送響應(yīng)。
結(jié)束語
對于很多 Ajax 和 Web 程序員來說，本文中介紹的內(nèi)容似乎是太高級了。生成 HEAD 請求的價值是什么呢？到底在什么情況下需要在 JavaScript 中顯式地處理重定向狀態(tài)代碼呢？這些都是很好的問題；對于簡單的應(yīng)用程序來說，答案是這些高級技術(shù)的價值并不是非常大。
然而，Web 已經(jīng)不再是只需實現(xiàn)簡單應(yīng)用程序的地方了；用戶已經(jīng)變得更加高級，客戶期望能夠獲得更好的穩(wěn)定性、更高級的錯誤報告，如果應(yīng)用程序有 1% 的時間停機，那么經(jīng)理就可能會因此而被解雇。
因此您的工作就不能僅僅局限于簡單的應(yīng)用程序了，而是需要更深入理解 XMLHttpRequest。
·如果您可以考慮各種就緒狀態(tài) —— 并且理解了這些就緒狀態(tài)在不同瀏覽器之間的區(qū)別 —— 就可以快速調(diào)試應(yīng)用程序了。您甚至可以基于就緒狀態(tài)而開發(fā)一些創(chuàng)造性的功能，并向用戶和客戶回報請求的狀態(tài)。
·如果您要對狀態(tài)代碼進行控制，就可以設(shè)置應(yīng)用程序來處理腳本錯誤、非預(yù)期的響應(yīng)以及邊緣情況。結(jié)果是應(yīng)用程序在所有的時間都可以正常工作，而不僅僅是只能一切都正常的情況下才能運行。
·增加這種生成 HEAD 請求的能力，檢查某個 URL 是否存在，以及確認(rèn)某個文件是否被修改過，這樣就可以確保用戶可以獲得有效的頁面，用戶所看到的信息都是最新的，（最重要的是）讓他們驚訝這個應(yīng)用程序是如何健壯和通用。
本文的目的并非是要讓您的應(yīng)用程序顯得十分華麗，而是幫助您去掉黃色聚光燈后重點昭顯文字的美麗，或者外觀更像桌面一樣。盡管這些都是 Ajax 的功能（在后續(xù)幾篇文章中就會介紹），不過它們卻像是蛋糕表面的一層奶油。如果您可以使用 Ajax 來構(gòu)建一個堅實的基礎(chǔ)，讓應(yīng)用程序可以很好地處理錯誤和問題，用戶就會返回您的站點和應(yīng)用程序。在接下來的文章中，我們將添加這種直觀的技巧，這會讓客戶興奮得發(fā)抖。（認(rèn)真地說，您一定不希望錯過下一篇文章?。?
相關(guān)文章
這篇文章主要介紹了Ajax驗證用戶名實例代碼，非常實用，特此分享供大家學(xué)習(xí)2016-04-04
這篇文章主要介紹了用ajax實現(xiàn)讀博客rss的具體實現(xiàn)，需要的朋友可以參考下2014-05-05
Ajax獲取回調(diào)函數(shù)無法賦值給全局變量的問題
這篇文章主要介紹了Ajax獲取回調(diào)函數(shù)無法賦值給全局變量的問題,需要的朋友可以參考下2018-06-06
雖然jquery的ajax要比原始的寫法容易得多，我們還是應(yīng)該了解原始的寫法，下面有個不錯的示例，大家可以參考下2014-04-04
ASP+AJAX+ACCESS數(shù)據(jù)庫實例講解三個步驟分享
其實說起AJAX的初級應(yīng)用是非常簡單的，通俗的說就是客戶端(javascript)與服務(wù)端(asp或php等)腳本語言的數(shù)據(jù)交互2012-07-07
這篇文章主要為大家詳細(xì)介紹了AJAX實現(xiàn)注冊驗證用戶名，文中示例代碼介紹的非常詳細(xì)，具有一定的參考價值，感興趣的小伙伴們可以參考一下2021-03-03
一個簡單的ASP+AJAX留言本源碼下載...2007-06-06
jquery中的ajax如何返回結(jié)果而非回調(diào)方式即為同順序執(zhí)行
默認(rèn)ajax是異步的，也就是在未響應(yīng)到結(jié)果時不影響向下的執(zhí)行，如果非要返回結(jié)果的話，將ajax 中的參數(shù) async 改為 false，即為同順序執(zhí)行2014-05-05
下面小編就為大家?guī)硪黄猘jax快速解決參數(shù)過長無法提交成功的問題。小編覺得挺不錯的，現(xiàn)在就分享給大家，也給大家做個參考。一起跟隨小編過來看看吧2016-12-12
javascript請求servlet實現(xiàn)ajax示例(分享)
下面小編就為大家?guī)硪黄猨avascript請求servlet實現(xiàn)ajax示例(分享)。小編覺得挺不錯的，現(xiàn)在就分享給大家，也給大家做個參考。一起跟隨小編過來看看吧2017-06-06