Http Status 500, 404, 200 ...

2011-04-02 10:13

elivsit

閱讀(466)

評論(0)

編輯

舉報

500 Server Error

404 Not Found

200 OK

應答代碼，雖然是SIP的但同樣适用于HTTP，隻是加了一些東西

應答代碼

應答碼是包含了，并且擴充了HTTP/1.1應答碼。并不是所有的HTTP/1.1應答碼都适當應用，隻有在折裡指出的是适當的。其他HTTP/1.1應答碼不應當使用。并且，SIP也定義了新的應答碼系列，6xx。

1 臨時應答1xx

臨時應答，也就是消息性質的應答，标志了對方伺服器正在處理請求，并且還沒有決定最後的應答。如果伺服器處理請求需要花200ms以上才能産生終結應答的時候，它應當發送一個1xx應答。

注意1xx應答并不是可靠傳輸的。他們不會導緻用戶端傳送一個ACK應答。臨時性質的（1xx）應答可以包含消息體，包含會話描述。

1.1 100 Trying

這個應答表示下一個節點的伺服器已經接收到了這個請求并且還沒有執行這個請求的特定動作（比如，正在打開資料庫的時候）。這個應答，就像其他臨時應答一樣，種植了UAC重新傳送INVITE請求。100(Trying)應答和其他臨時應答不同的是，在這裡，它永遠不會被有狀态proxy轉發到上行流中。

1.2 180 Ringing

UA收到INVITE請求并且試圖提示給使用者。這個應答應當出世化一個本地回鈴。

1.3 818 Call is Being Forwarded(呼叫被轉發)

伺服器可以用這個應答代碼來表示呼叫正在轉發到另一個目的地集合。

1.4 182 Queued

當呼叫的對方暫時不能接收呼叫的時候，并且伺服器決定将呼叫排隊等候，而不是拒絕呼叫的時候，那麼就應當發出這個應答。當被叫方一旦恢複接收呼叫，他會傳回合适的終結應答。對于這個呼叫狀态，可以有一個表示原因的短語，比如：”5 calls queued;expected waiting time is 15minutes”。伺服器可以給出好幾個182（Queued）應答告訴呼叫方排隊的情況（比如排隊靠前了等等）。

1.5 183 會話進度

183（Session Progress）應答用于提示建立對話的進度資訊。Reason-Phrase（表達原因的句子）、頭域或者消息體可以用于提示呼叫進度的更消息的資訊。

2 成功資訊2xx

這個應答表示請求是成功的。

2.1 200 OK

請求已經處理成功。這個資訊取決于不同方法的請求的應答。

3 轉發請求3XX

3xx系列的應答是用于提示使用者的新位置資訊的，或者為了滿足呼叫而轉發的額外服務地點。

3.1 300 Multiple Choices

請求的位址有多個選擇，每個選擇都有自己的位址，使用者或者（UA）可以選擇合适的通訊終端，并且轉發這個請求到這個位址。

應答可以包含一個具有每一個地點的在Accept請求頭域中允許的資源特性，這樣使用者或者UA可以選擇一個最合适的位址來轉發請求。沒有未這個應答的消息體定義MIME類型。

這些位址選擇也應當在Contact頭域中列出（20.10節）。不同于HTTP，SIP應答可以包含多個Contact頭域或者一個 Contact頭域中具有一個位址清單。UA可以使用Contact頭域來自動轉發或者要求使用者确認轉發。不過，本規範沒有定義自動轉發的标準。

如果被叫方可以在多個位址被找到，并且伺服器不能或者不願意轉發請求的時候，可以使用這個應答來給呼叫方。

3.2 301 Moved Permently

當不能在Request-URI指定的位址找到使用者的時候，請求的用戶端應當使用Contact頭域(20.10)所指出的新的位址重新嘗試。請求者應當用這個新的值來更新本地的目錄，位址本，和使用者位址cache，并且在後續請求中，發送到這個/這些列出的位址。

3.3 302 Moved Temporarily

請求方應當把請求重新發到這個Contact頭域所指出的新位址(20.10)。新請求的Request-URI應當用這個應答的Contact頭域所指出的值。

在應答中的Expires(20.19節)或者Contact頭域的expires參數定義了這個Contact URI的生存周期。UA或者proxy在這個生存周期内cache這個URI。如果沒有嚴格的有效時見，那麼這個位址僅僅本次有效，并且不能在以後的事務中儲存。

如果cache的Contact頭域的值失敗了，那麼被轉發請求的Request-URI應當再次嘗試一次。臨時URI可以比逾時時間更快的失效，并且可以有一個新的臨時URI。

3.4 305 Use Proxy

請求的資源必須通過Contact頭域中指出的proxy來通路。Contact頭域指定了一個proxy的URI。接收到這個應答的對象應當通過這個proxy重新發送這個單個請求。305（UseProxy）必須是UAS産生的。

3.5 380 Alternative Service

呼叫不成工，但是可以嘗試另外的服務。另外的服務在應答的消息體中定義。消息體的格式在這裡沒有定義，可能在以後的規範中定義。

4 請求失敗4xx

4xx應答定義了特定伺服器響應的請求失敗的情況。用戶端不應當在不更改請求的情況下重新嘗試同一個請求。（例如，增加合适的認證資訊）。不過，同一個請求交給不同伺服器也許就會成功。

4.1 400 Bad Request

請求中的文法錯誤。Reason-Phrase應當标志這個詳細的文法錯誤，比如”Missing Call-ID header field”。

4.2 401 Unauthorized

請求需要使用者認證。這個應答是由UAS和注冊伺服器産生的，當407（Proxy Authentication Required）是proxy伺服器産生的。

4.3 402 Payment Required

保留/以後使用

4.4 403 Forbidden

服務端支援這個請求，但是拒絕執行請求。增加驗證資訊是沒有必要的，并且請求應當不被重試。

4.5 404 Not Found

伺服器傳回最終資訊：使用者在Request-URI指定的域上不存在。當Request-URI的domain和接收這個請求的domain不比對的情況下，也會産生這個應答。

4.6 405 Method Not Allowed

伺服器支援Request-Line中的方法，但是對于這個Request-URI中的位址來說，是不允許應用這個方法的。

應答必須包括一個Allow頭域，這個頭域包含了指定位址允許的方法清單。

4.7 Not Acceptable

請求中的資源隻會導緻産生一個在請求中的Accept頭域外的，内容無法接收的錯誤。

4.8 407 Proxy Authentication Required

這個傳回碼和401（Unauthorized）很類四，但是标志了用戶端應當首先在proxy上通過認證。SIP對認證的通路請參見26節和22.3節。

這個傳回碼用于應用程式通路通訊網關（比如，電話網關），而很少用于被叫方要求認證。

4.9 408 Request Timeout

在一段時間内，伺服器不能産生一個終結應答，例如，如果它無法及時決定使用者的位置。用戶端可以在稍後不更改請求的内容然後重新嘗試請求。

4.10 410 Gone

請求的資源在本伺服器上已經不存在了，并且不知道應當把請求轉發到哪裡。這個問題将會使永久性的。如果伺服器不知道，或者不容易檢測，這個資源消失是臨時性質的還是永久性質的，那麼應當傳回一個404（Not Found）。

4.11 413請求實體過大。

伺服器拒絕處理請求，因為這個請求的實體超過了伺服器希望或者能夠處理的大小。這個伺服器應當關閉連接配接避免用戶端重發這個請求。

如果這個情況是暫時的，那麼服務端應當包含一個Retry-After頭域來表明這是一個暫時的故障，并且用戶端可以過一段時間再次嘗試。

4.12 414 Request-URI Too Long

伺服器拒絕這個請求，因為Request-URI超過了伺服器能夠處理的長度。

4.13 415 Unsupported Media Type

伺服器由于請求的消息體的格式本伺服器不支援，是以拒絕處理這個請求。這個伺服器必須根據内容的故障類型，傳回一個Accept，Accpet-Encoding,或者Accept-Language頭域清單。UAC根據8.1.3.5節定義的方法處理這個應答。

4.14 416 Unsupported URI Scheme

伺服器由于不支援Request-URI中的URI方案而終止處理這個請求。用戶端處理這個應答參照8.1.3.5。

4.15 Bad Extension

伺服器不知道在請求中的Proxy-Require(20.29)或者Require(20.32)頭域所指出的協定擴充。伺服器必須在Unsupported頭域中列出不支援的擴充。UAC處理這個應答請參見8.1.3.5

4.16 421Extension Required

UAS需要特定的擴充來處理這個請求，但是這個擴充并沒有在請求的Supported頭域中列出。具有這個應答碼的應答必須包含一個Require頭域列出所需要的擴充。

UAS不應當使用這個應答除非它真的不能給用戶端提供有效的服務。相反，如果在Support頭域中沒有列出需要的擴充，伺服器應當根據基準的SIP相容的方法和用戶端支援的擴充來進行處理。

4.17 423 Interval Too Brief

伺服器因為在請求中設定的資源重新整理時間（或者有效時間）過短而拒絕請求。這個應答可以用于注冊伺服器來拒絕那些Contact頭域有效期過短的注冊請求。這個應答的用法和相關的Min-Expires頭域在10.2.8,10.3,20.23節中介紹和說明。

4.18 480 Temporarily Unavailable

請求成功到達被叫方的終端系統，但是被叫方目前不可用（例如，沒有登陸，或者登陸了但是狀态是不能通訊，或者有”請勿打擾”的标記）。應答應當在 Retry-After中标志一個合适的重發時間。這個使用者也有可能在其他地方是有效的（在本伺服器中不知道）。Reason-Phrase(原因短句) 應當提示更詳細的原因，為什麼被叫方暫時不可用。這個值應當是可以被UA設定的。狀态碼486（Busy Here）可以用來更精确的表示本請求失敗的特定原因。

這個狀态碼也可以是轉發服務或者proxy伺服器傳回的，因為他們發現Request-URI指定的使用者存在，但是沒有一個給這個使用者的合适的目前轉發的位址。

4.19 481 Call/Transaction Does Not Exist

這個狀态表示了UAS接收到請求，但是沒有和現存的對話或者事務比對。

4.20 482 Loop Detected

伺服器檢測到了一個循環(16.3/4)

4.21 483 Too Many Hops

伺服器接收到了一個請求包含的Max-Forwards(20.22)頭域是0

4.22 484 Address InComplete

伺服器接收到了一個請求，它的Request-URI是不完整的。在原因短語中應當有附加的資訊說明。這個狀态碼可以和撥号交疊。在和撥号交疊中，用戶端不知道撥号串的長度。它發送增加長度的字串，并且提示使用者輸入更多的字串，直到不在出現484（Address Incomplete）應答為止。

4.23 485 Ambiguous

Request-URI是不明确的。應答可以在Contact頭域中包含一個可能的明确的位址清單。這個提示清單肯囊個在安全性和隐私性對使用者或者組織造成破壞。必須能夠由配置決定是否以404（NotFound）代替這個應答，又或者禁止對不明确的位址使用可能的選擇清單。

給帶有Request-URI的請求的一個應答例子：

sip: [email protected]:

SIP/2.0 485 Ambiguous

Contact: Carol Lee

Contact: Ping Lee

Contact: Lee M.Foote

部分email和語音郵箱系統提供了這個功能。這個狀态碼和3xx狀态碼不同：對于300來說，它是假定同一個人或者服務有不同的位址選擇。是以對3xx來說，自動選擇系統或者連續查找就有效，但是對485（Ambiguous）應答來說，一定要使用者的幹預。

4.24 486 Busy Here

當成功聯系到被叫方的終端系統，但是被叫方目前在這個終端系統上不能接聽這個電話，那麼應答應當回給呼叫方一個更合适的時間在Retry- After頭域重試。這個使用者也許在其他地方有效，比如電話郵箱系統等等。如果我們知道沒有其他終端系統能夠接聽這個呼叫，那麼應當傳回一個狀态碼 600（Busy Everywhere）。

4.25 487 Request Terminated

請求被BYE或者CANCEL所終止。這個應答永遠不會給CANCEL請求本身回複。

4.26 488 Not Acceptable Here

這個應答和606（Not Acceptable）有相同的含義，但是隻是應用于Request-URI所指出的特定資源不能接受，在其他地方請求可能可以接受。

包含了媒體相容性描述的消息體可以出現在應答中，并且根據INVITE請求中的Accept頭域進行規格化（如果沒有Accept頭域，那麼就是application/sdp）。這個應答就像給OPTIONS請求的200(OK)應答的消息體一樣。

4.27 491 Request Pending

在同一個對話中，UAS接收到的請求有一個依賴的請求正在處理。14.2描述了這種情況應當怎樣解決。

4.28 493 Undecipherable

UAS接收到了一個請求，包含了一個加密的MIME,并且不知道或者沒有提供合适的解密密鑰。這個應答可以包含單個包體，這個包體包含了合适的公鑰，這個公鑰用于給這個UAS通訊中加密包體使用的。細節描述在23.2節。

5 Server Failure 5xx

5xx應答是當伺服器本身故障的時候給出的失敗應答。

5.1 500 Server Internal Error

伺服器遇到了未知的情況，并且不能繼續處理請求。用戶端可以顯示特定的錯誤情況，并且可以在幾秒種以後重新嘗試這個請求。

如果這個情況是臨時的，伺服器應當在Retry-After頭域标志用戶端過多少秒鐘之後重新嘗試這個請求。

5.2 501 Not Implemented

伺服器沒有實作相關的請求功能。當UAS不認識請求的方法的時候，并且對每一個使用者都無法支援這個方法的時候，應當傳回這個應答。（proxy不考慮請求的方法而轉發請求）。

注意405（Method Not Allowed）是因為伺服器實作了這個請求方法，但是這個請求方法在特定請求中不被支援。

5.3 502 Bad Gateway

如果伺服器，作為gateway或者proxy存在，從下行伺服器上接收到了一個非法的應答（這個應答對應的請求是本伺服器為了完成請求而轉發給下行伺服器的）。

5.4 503 Service Unavailable

由于臨時的過載或者伺服器管理導緻的伺服器暫時不可用。這個伺服器可以在應答中增加一個Retry-After來讓用戶端重試這個請求。如果沒有Retry-After指出，用戶端必須就像收到了一個500（Server Internal Error）應答一樣處理。

用戶端（proxy或者UAC）收到503（Service Unavailable）應當嘗試轉發這個請求到另外一個伺服器處理。并且在Retry-After頭域中指定的時間内，不應當轉發其他請求到這個伺服器。

作為503(Service Unavaliable)的替代，伺服器可以拒絕連接配接或者把請求扔掉。

5.5 504 Server Time-out

伺服器在一個外部伺服器上沒有收到一個及時的應答。這個外部伺服器是本伺服器用來通路處理這個請求所需要的。如果從上行伺服器上收到的請求中的Expires頭域逾時，那麼應當傳回一個408（Request TimeOut）錯誤。

5.6 505 Version Not Supported

伺服器不支援對應的SIP版本。伺服器是無法處理具有用戶端提供的相同主版本号的請求，就會導緻這樣的錯誤資訊。

5.7 Message To Large

伺服器無法處理請求，因為消息長度超過了處理的長度。

6 Global Failures 6xx

6xx應答意味這伺服器給特定使用者有一個最終的資訊，并不隻是在Request-URI的特定執行個體有最終資訊。

6.1 600 Busy Everywhere

成功聯系到被叫方的終端系統，但是被叫方處于忙的狀态，并不打算接聽電話。這個應答可以通過增加一個Retry-After頭域更明确的告訴呼叫方多久以後可以繼續呼叫。如果被叫方不希望提示拒絕的原因，被叫方應當使用603（Decline）。隻有當終端系統知道沒有其他終端節點（比如語音郵箱系統）能夠通路到這個使用者的時候才能使用這個應答。否則應當傳回一個486（Busy Here）的應答。

6.2 603 Decline

當成功通路到被叫方的裝置，但是使用者明确的不想應答。這個應答可以通過增加一個Retry-After頭域更明确的告訴呼叫方多久以後可以繼續呼叫。隻有當終端知道沒有其他任何終端裝置能夠響應這個呼叫的勢能才能給出這個應答。

6.3 604 Does Not Exists Anywhere

伺服器驗證了在請求中Request-URI的使用者資訊，哪裡都不存在

6.4 606 Not Acceptable

當成功聯系到一個UA,但是會話描述的一些部分比如請求的媒體，帶寬，或者位址類型不被接收。

606（NotAcceptable）應答意味着使用者希望通訊，但是不能充分支援會話描述。606（Not Acceptable）應答可以在Warning頭域中包含一個原因清單，用于解釋為何會話描述不能被支援。警告原因代碼在20.43節中列出。

在應答中，可以出現一個包含媒體相容性描述的消息體，這個消息體的格式根據INVITE請求中的Accept頭域指出的格式進行規格化（如果沒有Accept頭域，那麼就是application/sdp），就像給OPTIONS親求的200(OK)應答中的消息一樣。

我們希望這些媒體協商不要經常需要，并且當一個新使用者被邀請加入已經存在的會話的時候，這個媒體協商可能不需要。這取決于邀請的初始化者是否需要對606（Not Acceptable）進行處理。

這個應答隻有當用戶端知道沒有其他終端能夠處理這個請求的時候才能發出。

分類 Asp.Net