Spring MVC，HTTP Status 400 ，jQuery

1、先看下4xx錯誤的說明

【轉載】 http status 400,http 400,400 錯誤

【參考】 status code 400, Bad Request (§10.4.1)

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: lee@example.com: 
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通信中加密包體使用的。

http status 400,http 400,400 錯誤

2、Spring MVC出現：HTTP status 400 The request sent by the client was syntactically incorrect.

    首先，400 是請求中的語法錯誤。

    那麼，請求的語法有哪些呢？

    碰見的語法錯誤有：

        表單提交的name的值和服務器（Spring MVC中的Controller）對應的參數的類型不一致（怎麼不一致的？就像服務器原本接受的是整數（int）的，可是客戶端傳遞的倒是一個浮點數（double,float））。

    那麼可不可經過400語法錯誤來預測服務對應的參數呢？

    若是是使用Spring MVC做爲服務器端的話，咱們可能會定義一個Bean來綁定前臺傳來的參數（我想只要使用過Spring MVC的人都會這麼作），咱們是否是能夠經過form表單的name的具體值來輸入可能的值，來預測Bean中對應字段的類型呢（能夠一試）？

    小結，Spring MVC出現400語法 錯誤的話，應該要找的客戶端傳遞的值和Controller對應的參數的類型是否一致，而且Spring MVC的後臺是不會報錯的，若是使用了Log4J的話能夠將日誌設置debug級別

log4j.rootLogger=DEBUG

示例以下：

Field error in object 'article' on field 'type': rejected value [11.0]; codes [typeMismatch.article.type,typeMismatch.type,typeMismatch.java.lang.Integer,typeMismatch]; arguments [org.springframework.context.support.DefaultMessageSourceResolvable: codes [article.type,type]; arguments []; default message [type]]; default message [Failed to convert property value of type 'java.lang.String' to required type 'int' for property 'type'; nested exception is java.lang.NumberFormatException: For input string: "11.0"]
2015-04-28 21:42:23 DEBUG org.springframework.web.servlet.handler.AbstractHandlerExceptionResolver.resolveException(AbstractHandlerExceptionResolver.java:134) - Resolving exception from handler [public java.lang.Object org.jast.mybatis.cms.controller.ArticleController.add(org.jast.mybatis.cms.entity.Article)]: org.springframework.validation.BindException: org.springframework.validation.BeanPropertyBindingResult: 1 errors
Field error in object 'article' on field 'type': rejected value [11.0]; codes [typeMismatch.article.type,typeMismatch.type,typeMismatch.java.lang.Integer,typeMismatch]; arguments [org.springframework.context.support.DefaultMessageSourceResolvable: codes [article.type,type]; arguments []; default message [type]]; default message [Failed to convert property value of type 'java.lang.String' to required type 'int' for property 'type'; nested exception is java.lang.NumberFormatException: For input string: "11.0"]
2015-04-28 21:42:23 DEBUG org.springframework.web.servlet.handler.AbstractHandlerExceptionResolver.resolveException(AbstractHandlerExceptionResolver.java:134) - Resolving exception from handler [public java.lang.Object org.jast.mybatis.cms.controller.ArticleController.add(org.jast.mybatis.cms.entity.Article)]: org.springframework.validation.BindException: org.springframework.validation.BeanPropertyBindingResult: 1 errors
Field error in object 'article' on field 'type': rejected value [11.0]; codes [typeMismatch.article.type,typeMismatch.type,typeMismatch.java.lang.Integer,typeMismatch]; arguments [org.springframework.context.support.DefaultMessageSourceResolvable: codes [article.type,type]; arguments []; default message [type]]; default message [Failed to convert property value of type 'java.lang.String' to required type 'int' for property 'type'; nested exception is java.lang.NumberFormatException: For input string: "11.0"]