xmlHttp的readyState 和 status參數詳解

AJAX中檢查狀態碼的代碼:

readyState 和status都是什麼意思呢?

XMLHTTP 的 readyState 值含義:

  • 0-未初始化,即尚未調用 open。
  • 1-初始化,即尚未調用 send。
  • 2-發送數據,即已經調用 send。
  • 3-數據傳送中。
  • 4-完成。

    HTTP 服務器狀態代碼定義

     

    1.1 消息 1xx Informational 1xx

    該類狀態代碼用於表示臨時迴應。 臨時迴應由狀態行( Status-Line )及可選標題組成, 由空行終止。 HTTP/1.0 中沒有定義任何 1xx 的狀態代碼,所以它們不是對 HTTP/1.0 請求的合法迴應。實 際上,它們主要用於實驗用途,這已經超出本文檔的範圍。

     

    1.2 成功 2xx Successful 2xx

    表示客戶端請求被成功接收、理 解、接受。

    200 OK

    請求成功。迴應的信息依賴於請求 所使用的方法,如下:

    GET 要請求的資源已經放在迴應的 實體中了。

    HEAD 沒有實體主體,迴應中只包 括標題信息。  

    POST 實體(描述或包含操作的結 果)。

    201 Created

    請求完成,結果是創建了新資源。 新創建資源的 URI 可在迴應的實體中得到。原始服務器應在發出該狀態代碼前創建該資源。如果該操作不能立即完成,服務 器必須在該資源可用時在迴應主體中給出提示,否則,服務器端應迴應 202 (可被接受)。

    在本文定義的方法,只有 POST 可以創建資源。

    202 Accepted

    請求被接受,但處理尚未完成。請 求可能不一定會最終完成,有可能被處理過程隨時中斷,在這種情況下,沒有辦法在異步操作中重新發送狀態代碼。

    202 迴應是沒有義務的,這樣做的目 的是允許服務器不必等到用戶代理和服務器間的連接結束,就可以響應其它過程的請求(象每天運行一次的,基於批處理的過程)。

    在某些迴應中返回的實體中包括當 前請求的狀態指示、狀態監視器指針或用戶對請求能否實現的評估信息。

    204 No Content

    服務器端已經實現了請求,但是沒 有返回新的信息。如果客戶是用戶代理,則勿需爲此更新自身的文檔視圖。該回應主要是爲了在不影響用戶代理激活文檔視圖的前提下,進行 script 語句的輸入及其它操作。該回應還可能包括新的、以實體標題形式表示的元信息,它可被當前用戶代理激 活視圖中的文檔所使用。

     

    1.3 重定向( Redirection 3xx

    該類狀態碼錶示用戶代理要想完成 請求,還需要發出進一步的操作。這些操作只有當後跟的請求是 GET HEAD 時,纔可由用戶代理來實現,而不用與用戶進行交互。用戶代理永遠也不要對請求進行 5 次以上的重定向操作,這樣可能導致無限循環。

    300 Multiple Choices

    該狀態碼不被 HTTP/1.0 的應用程序直接使用,只是做爲 3xx 類型迴應的缺省解釋。存在多個可用的被請求資源。

    除非是 HEAD 請求,否則迴應的實體中必須包括這些資源的字符列表及位置信息,由用戶或用戶代理來決定哪個是最適 合的。

    如果服務器有首選,它應將對應的 URL 信息存放在位置域( Location field )處,用戶代理會根據此域的值來實現自動的重定向。

    301 Moved Permanently

    請求到的資源都會分配一個永久的 URL ,這樣就可以在將來通過該 URL 來訪問此資源。有編輯鏈接功能的客戶端會儘可能地根據服務器端傳回的新鏈接而自動更新請求 URI 。新的 URL 必須由迴應中的位置域指定。除非是 HEAD 請求,否則迴應的實體主體( Entity-Body )必須包括對新 URL 超鏈接的簡要描述。

    如果用 POST 方法發出請求,而接收到 301 迴應狀態碼。在這種情況下,除非用戶確認,否則用戶代理不必自動重定向請求,因爲這將導致改變已發出請求的環境。

    注意:當在接收到 301 狀態碼後而自動重定向 POST 請求時,一些現存的用戶代理會錯誤地將其改爲 GET 請求。

    302 Moved Temporarily

    請求到的資源在一個不同的 URL 處臨時保存。因爲重定向有時會被更改,客戶端應繼續用請求 URI 來發出以後的請求。新的 URL 必須由迴應中的位置域指定。除非是 HEAD 請求,否則迴應的實體主體( Entity-Body )必須包括對新 URL 超鏈接的簡要描述。

    如果用 POST 方法發出請求,而接收到 302 迴應狀態碼。在這種情況下,除非用戶確認,否則用戶代理不必自動重定向請求,因爲這將導致改變已發出請求的環境。

    注意:當在接收到 302 狀態碼後而自動重定向 POST 請求時,一些現存的用戶代理會錯誤地將其改爲 GET 請求。

    304 Not Modified

    如果客戶端成功執行了條件 GET 請求,而對應文件自 If-Modified-Since 域所指定的日期以來就沒有更新過,服務器應當迴應此狀態碼,而不是將實體主體發送給客戶端。迴應標題 域中只應包括一些相關信息,比如緩存管理器、與實體最近更新( entity's Last-Modified )日期無關的修改。相關標題域的例子有:日期、服務器、過期時間。每當 304 迴應中給出的域值發生變化,緩存都應當對緩存的實體進行更新。

     

    1.4 客戶端錯誤( Client Error 4xx

    4xx 類的狀態碼錶示客戶端發生錯 誤。如果客戶端在收到 4xx 代碼時請求還沒有完成,它應當立即終止向服務器發送數據。除了迴應 HEAD 請求外,不論錯誤是臨時的還是永久的,服務器端都必須在迴應的實體中包含錯誤狀態的解釋。這些狀態 碼適用於任何請求方法。

    注意:如果客戶端正在發送數據, 服務器端的 TCP 實現應當小心,以確保客戶端在關閉輸入連接之前收到迴應包。如果客戶端在關閉後仍舊向服務器發送數 據,服務器會給客戶  端發送一個復位包,清空客戶端尚未處理的輸入緩衝區,以終止 HTTP 應用程序的讀取、解釋活動。

    400 非法請求( Bad Request

    如果請求的語法不對,服務器將無 法理解。客戶端在對該請求做出更改之前,不應再次向服務器重複發送該請求。

    401 未授權( Unauthorized

    請求需要用戶授權。迴應中的 WWW-Authenticate 標題域( 10.16 節)應提示用戶以授權方式請求資源。客戶端應使用合適的授權標題域( 10.2 節)來重複該請求。如果請求中已經包括了授權信任信息,那回應的 401 表示此授權被拒絕。如果用戶代理在多次嘗試之後,迴應一樣還是返回 401 狀態代碼,用戶應當察看一下回應的實體,因爲在實體中會包括一些相關的動態信息。 HTTP 訪問授權會在 11 節中解釋。

    403 禁止( Forbidden

    服務器理解請求,但是拒絕實現該 請求。授權對此沒有幫助,客戶端應當停止重複發送此請求。如果不是用 HEAD 請求方法,而且服務器端願意公佈請求未被實現原因的前提下,服務器會將拒絕原因寫在迴應實體中。該狀 態碼一般用於服務器端不想公佈請求被拒絕的細節或沒有其它的迴應可用。

    404 沒有找到( Not Found

    服務器沒有找到與請求 URI 相符的資源。 404 狀態碼並不指明狀況是臨時性的還是永久性的。如果服務器不希望爲客戶端提供這方面的信息,還回應 403 (禁止)狀態碼。

     

    1.5 服務器錯誤( Server Error 5xx

    迴應代碼以‘ 5 ’開頭的狀態碼錶示服務器端發現自己出現錯誤,不能繼續執行請求。如果客戶端在收到 5xx 狀態碼時,請求尚未完成,它應當立即停止向服務器發送數據。除了迴應 HEAD 請求外,服務器應當在其迴應實體中包括對錯誤情況的解釋、並指明是臨時性的還永久性的。

    這類迴應代碼沒有標題域,可適用 於任何請求方法。

    500 服務器內部錯誤( Internal Server Error

    服務器碰到了意外情況,使其無法 繼續迴應請求。

    501 未實現( Not Implemented

    服務器無法提供對請求中所要求功 能的支持。如果服務器無法識別請求方法就會迴應此狀態代碼,這意味着不能迴應請求所要求的任何資源。

    502 非法網關( Bad Gateway

    充當網關或代理的服務器從要發送 請求的上游( upstream )服務器收到非法的迴應。

    503 服務不可用( Service Unavailable

    服務器當前無法處理請求。這一般 是由於服務器臨時性超載或維護引起的。該狀態碼暗示情況是暫時性的,要產生一些延遲。

    注意: 503 狀態碼並沒有暗示服務器在超載時一定要返回此狀態碼。一些服務器可能希望在超載時採用簡單處理,即 斷掉連接。

     

    IIS 錯誤代碼大彙總

    400 無法解析此請求。

    401.1 未經授權:訪問由於憑據 無效被拒絕。

    401.2 未經授權 : 訪問由於服務器配置傾向使用替代身份驗證方法而被拒絕。

    401.3 未經授權:訪問由於 ACL 對所請求資源的設置被拒絕。

    401.4 未經授權: Web 服務器上安裝的篩選器授權失敗。

    401.5 未經授權: ISAPI/CGI 應用程序授權失敗。

    401.7 未經授權:由於 Web 服務器上的 URL 授權策略而拒絕訪問。

    403 禁止訪問:訪問被拒絕。

    403.1 禁止訪問:執行訪問被拒 絕。

    403.2 禁止訪問:讀取訪問被拒 絕。

    403.3 禁止訪問:寫入訪問被拒 絕。

    403.4 禁止訪問:需要使用 SSL 查看該資源。

    403.5 禁止訪問:需要使用 SSL 128 查看該資源。

    403.6 禁止訪問:客戶端的 IP 地址被拒絕。

    403.7 禁止訪問:需要 SSL 客戶端證書。

    403.8 禁止訪問:客戶端的 DNS 名稱被拒絕。

    403.9 禁止訪問:太多客戶端試 圖連接到 Web 服務器。

    403.10 禁止訪問: Web 服務器配置爲拒絕執行訪問。

    403.11 禁止訪問:密碼已更 改。

    403.12 禁止訪問:服務器證書 映射器拒絕了客戶端證書訪問。

    403.13 禁止訪問:客戶端證書 已在 Web 服務器上吊銷。

    403.14 禁止訪問:在 Web 服務器上已拒絕目錄列表。

    403.15 禁止訪問: Web 服務器已超過客戶端訪問許可證限制。

    403.16 禁止訪問:客戶端證書 格式錯誤或未被 Web 服務器信任。

    403.17 禁止訪問:客戶端證書 已經到期或者尚未生效。

    403.18 禁止訪問:無法在當前 應用程序池中執行請求的 URL

    403.19 禁止訪問:無法在該應 用程序池中爲客戶端執行 CGI

    403.20 禁止訪問: Passport 登錄失敗。

    404 找不到文件或目錄。

    404.1 文件或目錄未找到:網站 無法在所請求的端口訪問。

    注意 404.1 錯誤只會出現在具有多個 IP 地址的計算機上。如果在特定 IP 地址 / 端口組合上收到客戶端請求,而且沒有將 IP 地址配置爲在該特定的端口上偵聽,則 IIS 返回 404.1 HTTP 錯誤。例如,如果一臺計算機有兩個 IP 地址,而只將其中一個 IP 地址配置爲在端口 80 上偵聽,則另一個 IP 地址從端口 80 收到的任何請求都將導致 IIS 返回 404.1 錯誤。只應在此服務級別設置該錯誤,因爲只有當服務器上使用多個 IP 地址時纔會將它返回給客戶端。

    404.2 文件或目錄無法找到:鎖 定策略禁止該請求。

    404.3 文件或目錄無法找到: MIME 映射策略禁止該請求。

    405 用於訪問該頁的 HTTP 動作未被許可。

    406 客戶端瀏覽器不接受所請求頁 面的 MIME 類型。

    407 Web 服務器需要初始的代 理驗證。

    410 文件已刪除。

    412 客戶端設置的前提條件在 Web 服務器上評估時失敗。

    414 請求 URL 太大,因此在 Web 服務器上不接受該 URL

    500 服務器內部錯誤。

    500.11 服務器錯誤: Web 服務器上的應用程序正在關閉。

    500.12 服務器錯誤: Web 服務器上的應用程序正在重新啓動。

    500.13 服務器錯誤: Web 服務器太忙。

    500.14 服務器錯誤:服務器上 的無效應用程序配置。

    500.15 服務器錯誤:不允許直 接請求 GLOBAL.ASA

    500.16 服務器錯誤: UNC 授權憑據不正確。

    500.17 服務器錯誤: URL 授權存儲無法找到。

    500.18 服務器錯誤: URL 授權存儲無法打開。

    500.19 服務器錯誤:該文件的 數據在配置數據庫中配置不正確。

    500.20 服務器錯誤: URL 授權域無法找到。

    500.100 內部服務器錯誤: ASP 錯誤。

    501 標題值指定的配置沒有執行。

    502 Web 服務器作爲網關或代 理服務器時收到無效的響應。

  • 來源:http://blog.csdn.net/xiaxiaorui2003/archive/2009/04/16/4084115.aspx
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章