學習筆記：掌握Ajax第 3 部分： Ajax 中的進階請求和響應（續）

 掌握Ajax第 3 部分： Ajax 中的進階請求和響應（續）2006-11-19 17:42

這對於 Ajax 編程來說證明是一種短視而錯誤的方法。如果指令碼需要認證，而請求卻沒有提供有效認證，那麼伺服器就會返回諸如 403 或 401 之類的錯誤碼。然而，由於伺服器對請求進行了應答，因此就緒狀態就被設定為 4（即使應答並不是請求所期望的也是如此）。最終，使用者沒有獲得有效資料，當 JavaScript 試圖使用不存在的伺服器資料時就可能會出現嚴重的錯誤。 它花費了最小的努力來確保伺服器不但完成了一個請求，而且還返回了一個 “一切良好” 的狀態碼。這個代碼是 "200"，它是通過 XMLHttpRequest 對象的 status 屬性來報告的。為了確保伺服器不但完成了一個請求，而且還報告了一個 OK 狀態，請在您的回呼函數中添加另外一個檢查功能，如 清單 7 所示。 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); } } 通過添加這幾行代碼，您就可以確認是否存在問題，使用者會看到一個有用的錯誤訊息，而不僅僅是看到一個由斷章取義的資料所構成的頁面，而沒有任何解釋。   在深入介紹有關錯誤的內容之前，我們有必要來討論一下有關一個在使用 Ajax 時 並不需要 關心的問題 —— 重新導向。在 HTTP 狀態碼中，這是 300 系列的狀態碼，包括： 301：永久移動 302：找到（請求被重新定向到另外一個 URL/URI 上） 305：使用代理（請求必須使用一個代理來訪問所請求的資源） Ajax 程式員可能並不太關心有關重新導向的問題，這是由於兩方面的原因： 首先，Ajax 應用程式通常都是為一個特定的伺服器端指令碼、servlet 或應用程式而編寫的。對於那些您看不到就消失了的組件來說，Ajax 程式員就不太清楚了。因此有時您會知道資源已經移動了（因為您移動了它，或者通過某種手段移動了它），接下來要修改請求中的 URL，並且不會再碰到這種結果了。 更為重要的一個原因是：Ajax 應用程式和請求都是封裝在沙箱中的。這就意味著提供產生 Ajax 請求的 Web 頁面的域必須是對這些請求進行響應的域。因此 ebay.com 所提供的 Web 頁面就不能對一個在 amazon.com 上啟動並執行指令碼產生一個 Ajax 風格的請求；在 ibm.com 上的 Ajax 應用程式也無法對在 netbeans.org 上啟動並執行 servlets 發出請求。 結果是您的請求無法重新導向到其他伺服器上，而不會產生安全性錯誤。在這些情況中，您根本就不會得到狀態碼。通常在偵錯主控台中都會產生一個 JavaScript 錯誤。因此，在對狀態碼進行充分的考慮之後，您就可以完全忽略重新導向代碼的問題了。 看到現在，一些新手程式員就可能會這究竟是要討論什麼內容。有一點事實大家需要知道：只有不到 5% 的 Ajax 請求需要使用諸如 2、3 之類的就緒狀態和諸如 403 之類的狀態碼（實際上，這個比率可能更接近於 1% 甚至更少）。這些情況非常重要，稱為 邊界情況（edge case） —— 它們只會在一些非常特殊的情況下發生，其中遇到的都是最奇特的問題。雖然這些情況並不普遍，但是這些邊界情況卻佔據了大部分使用者所碰到的問題的 80%! 對於典型的使用者來說，應用程式 100 次都是正常工作的這個事實通常都會被忘記，然而應用程式只要一次出錯就會被他們清楚地記住。如果您可以很好地處理邊界情況（或困難情況），就可以為再次訪問網站的使用者提供滿意的回報。   一旦接收到狀態碼 200 並且意識到可以很大程度上忽略 300 系列的狀態碼之後，所需要擔心的唯一一組代碼就是 400 系列的代碼了，這說明了不同類型的錯誤。回頭再來看一下 清單 7，並注意在對錯誤進行處理時，只將少數常見的錯誤訊息輸出給使用者了。儘管這是朝正確方向前進的一步，但是要告訴從事應用程式開發的使用者和程式員究竟發生了什麼問題，這些訊息仍然是沒有太大用處的。 首先，我們要添加對找不到的頁的支援。實際上這在大部分產品系統中都不應該出現，但是在測試指令碼位置發生變化或程式員輸入了錯誤的 URL 時，這種情況並不罕見。如果您可以自然地報告 404 錯誤，就可以為那些困擾不堪的使用者和程式員提供更多協助。例如，如果伺服器上的一個指令碼被刪除了，我們就可以使用 清單 7 中的代碼，這樣使用者就會看到一個如 圖 5 所示的非描述性錯誤。 使用者無法判斷問題究竟是認證問題、沒找到指令碼（此處就是這種情況）、使用者錯誤還是代碼中有些地方產生了問題。添加一些簡單的代碼可以讓這個錯誤更加具體。請參照 清單 8，它負責處理沒找到的指令碼或認證發生錯誤的情況，在出現這些錯誤時都會給出具體的訊息。 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); } } 雖然這依然相當簡單，但是它的確多提供了一些有用的資訊。圖 6 給出了與 圖 5 相同的錯誤，但是這一次錯誤處理代碼向使用者或程式員更好地說明了究竟發生了什麼。 在我們自己的應用程式中，可以考慮在發生認證失敗的情況時清除使用者名稱和密碼，並向螢幕上添加一條錯誤訊息。我們可以使用類似的方法來更好地處理找不到指令碼或其他 400 類型的錯誤（例如 405 表示不允許使用諸如發送 HEAD 請求之類不可接受的要求方法，而 407 則表示需要進行代理認證）。然而不管採用哪種選擇，都需要從對伺服器上返回的狀態碼開始入手進行處理。   如果您真希望控制 XMLHttpRequest 對象，可以考慮最後實現這種功能 —— 將 HEAD 請求添加到指令中。在前兩篇文章中，我們已經介紹了如何產生 GET 請求；在馬上就要發表的一篇文章中，您會學習有關使用 POST 請求將資料發送到伺服器上的知識。不過本著增強錯誤處理和資訊搜集的精神，您應該學習如何產生 HEAD 請求。   實際上產生 HEAD 請求非常簡單；您可以使用 "HEAD"（而不是 "GET" 或 "POST"）作為第一個參數來調用 open() 方法，如 清單 9 所示。 function getSalesData() { createRequest(); var url = "/boards/servlet/UpdateBoardSales"; request.open("HEAD", url, true); request.onreadystatechange = updatePage; request.send(null); } 當您這樣產生一個 HEAD 請求時，伺服器並不會像對 GET 或 POST 請求一樣返回一個真正的響應。相反，伺服器只會返回資源的 頭（header），這包括響應中內容最後修改的時間、請求資源是否存在和很多其他有用資訊。您可以在伺服器處理並返回資源之前使用這些資訊來瞭解有關資源的資訊。 對於這種請求您可以做的最簡單的事情就是簡單地輸出所有的回應標頭的內容。這可以讓您瞭解通過 HEAD 請求可以使用什麼。清單 10 提供了一個簡單的回呼函數，用來輸出從 HEAD 請求中獲得的回應標頭的內容。 function updatePage() { if (request.readyState == 4) { alert(request.getAllResponseHeaders()); } } 請參見 圖 7，其中顯示了從一個向伺服器發出的 HEAD 請求的簡單 Ajax 應用程式返回的回應標頭。 您可以單獨使用這些頭（從伺服器類型到內容類型）在 Ajax 應用程式中提供其他資訊或功能。   您已經看到了當 URL 不存在時應該如何檢查 404 錯誤。如果這變成一個常見的問題 —— 可能是缺少了一個特定的指令碼或 servlet —— 那麼您就可能會希望在產生完整的 GET 或 POST 請求之前來檢查這個 URL。要實現這種功能，產生一個 HEAD 請求，然後在回呼函數中檢查 404 錯誤；清單 11 給出了一個簡單的回呼函數。 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); } } } 誠實地說，這段代碼的價值並不太大。伺服器必須對請求進行響應，並構造一個響應來填充內容長度的回應標頭，因此並不能節省任何處理時間。另外，這花費的時間與產生請求並使用 HEAD 請求來查看 URL 是否存在所需要的時間一樣多，因為它要產生使用 GET 或 POST 的請求，而不僅僅是如 清單 7 所示一樣來處理錯誤碼。不過，有時確切地瞭解目前什麼可用也是非常有用的；您永遠不會知道何時創造力就會迸發或者何時需要 HEAD 請求！   您會發現 HEAD 請求非常有用的一個領域是用來查看內容的長度或內容的類型。這樣可以確定是否需要發回大量資料來處理請求，和伺服器是否試圖返回位元據，而不是 HTML、文本或 XML（在 JavaScript 中，這 3 種類型的資料都比位元據更容易處理）。 在這些情況中，您只使用了適當的頭名，並將其傳遞給 XMLHttpRequest 對象的 getResponseHeader() 方法。因此要擷取響應的長度，只需要調用 request.getResponseHeader("Content-Length");。要擷取內容類型，請使用 request.getResponseHeader("Content-Type");。 在很多應用程式中，產生 HEAD 請求並沒有增加任何功能，甚至可能會導致請求速度變慢（通過強制產生一個 HEAD 請求來擷取有關響應的資料，然後在使用一個 GET 或 POST 請求來真正擷取響應）。然而，在出現您不確定有關指令碼或伺服器端組件的情況時，使用 HEAD 請求可以擷取一些基本的資料，而不需要對響應資料真正進行處理，也不需要大量的頻寬來發送響應。   對於很多 Ajax 和 Web 程式員來說，本文中介紹的內容似乎是太進階了。產生 HEAD 請求的價值是什麼呢？到底在什麼情況下需要在 JavaScript 中顯式地處理重新導向狀態碼呢？這些都是很好的問題；對於簡單的應用程式來說，答案是這些進階技術的價值並不是非常大。 然而，Web 已經不再是只需實現簡單應用程式的地方了；使用者已經變得更加進階，客戶期望能夠獲得更好的穩定性、更進階的錯誤報表，如果應用程式有 1% 的時間停機，那麼經理就可能會因此而被解僱。 因此您的工作就不能僅僅局限於簡單的應用程式了，而是需要更深入理解 XMLHttpRequest。 如果您可以考慮各種就緒狀態 —— 並且理解了這些就緒狀態在不同瀏覽器之間的區別 —— 就可以快速調試應用程式了。您甚至可以基於就緒狀態而開發一些創造性的功能，並向使用者和客戶回報請求的狀態。 如果您要對狀態碼進行控制，就可以設定應用程式來處理指令碼錯誤、非預期的響應以及邊緣情況。結果是應用程式在所有的時間都可以正常工作，而不僅僅是只能一切都正常的情況下才能運行。 增加這種產生 HEAD 請求的能力，檢查某個 URL 是否存在，以及確認某個檔案是否被修改過，這樣就可以確保使用者可以獲得有效頁面，使用者所看到的資訊都是最新的，（最重要的是）讓他們驚訝這個應用程式是如何健壯和通用。 本文的目的並非是要讓您的應用程式顯得十分華麗，而是協助您去掉黃色聚光燈後重點昭顯文字的美麗，或者外觀更像案頭一樣。儘管這些都是 Ajax 的功能（在後續幾篇文章中就會介紹），不過它們卻像是蛋糕表面的一層奶油。如果您可以使用 Ajax 來構建一個堅實的基礎，讓應用程式可以很好地處理錯誤和問題，使用者就會返回您的網站和應用程式。在接下來的文章中，我們將添加這種直觀的技巧，這會讓客戶興奮得發抖。（認真地說，您一定不希望錯過下一篇文章！）