摘要:例如,服務端不支持這種,應該返回。而當使用或者其他等價方式進行配置時,會把添加在最前面,優先級最高。好了,到此就基本上說完了整個的匹配規則或者叫選擇過程。自己能力不是最大,卻大包大攬承擔最大責任,處理不了還返回,是甩鍋客戶端的行為。
以下內容,如有問題,煩請指出,謝謝!
SpringMVC啟動時會自動配置一些HttpMessageConverter,接收到http請求時,從這些Converters中選擇一個符合條件的來進行Http序列化/反序列化。在不覆蓋默認的HttpMessageConverters的情況下,我們添加的Converter可能會與默認的產生沖突,在某些場景中出現不符合預期的情況。
在上一篇文章的末尾已經列舉了一個jsonConverter沖突的情況:添加一個最低優先級的FastJsonConverter后會有兩個(實際上三個,有兩個jackson的)jsonConverter,直接使用瀏覽器訪問接口時使用的卻是低優先級的FastJsonConverter來進行序列化操作。
為了解決converters之間的沖突,或者直接叫優先級問題,需要弄懂SpringMVC是如何選擇一個HttpMessageMessagerConverter來進行Http序列化/反序列化的。這篇文章主要就根據相關的代碼來講解SpringMVC的這個內部流程,這塊的邏輯比較清晰,貼貼代碼就基本上都明白了。
首先需要了解一些HTTP的基本知識(不是強制的而是一種建議與約定):
1、決定resp.body的Content-Type的第一要素是對應的req.headers.Accept屬性的值,又叫做MediaType。如果服務端支持這個Accept,那么應該按照這個Accept來確定返回resp.body對應的格式,同時把resp.headers.Content-Type設置成自己支持的符合那個Accept的MediaType。服務端不支持Accept指定的任何MediaType時,應該返回錯誤406 Not Acceptable.
例如:req.headers.Accept = text/html,服務端支持的話應該讓resp.headers.Content-Type = text/html,并且resp.body按照html格式返回。
例如:req.headers.Accept = text/asdfg,服務端不支持這種MediaType,應該返回406 Not Acceptable。
2、如果Accept指定了多個MediaType,并且服務端也支持多個MediaType,那么Accept應該同時指定各個MediaType的QualityValue,也就是q值,服務端根據q值的大小來決定這幾個MediaType類型的優先級,一般是大的優先。q值不指定時,默認視為q=1.
Chrome的默認請求的Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,表示服務端在支持的情況下應該優先返回text/html,其次是application/xhtml+xml.
前面幾個都不支持時,服務器可以自行處理 */*,返回一種服務器自己支持的格式。
3、一個HTTP請求沒有指定Accept,默認視為指定 Accept: */*;沒有指定Content-Type,默認視為 null,就是沒有。當然,服務端可以根據自己的需要改變默認值。
4、Content-Type必須是具體確定的類型,不能包含 *.
SpringMvc基本遵循上面這幾點。
然后是啟動時默認加載的Converter。在mvc啟動時默認會加載下面的幾種HttpMessageConverter,相關代碼在 org.springframework.web.servlet.config.annotation.WebMvcConfigurationSupport中的addDefaultHttpMessageConverters方法中,代碼如下。
protected final void addDefaultHttpMessageConverters(List> messageConverters) { StringHttpMessageConverter stringConverter = new StringHttpMessageConverter(); stringConverter.setWriteAcceptCharset(false); messageConverters.add(new ByteArrayHttpMessageConverter()); messageConverters.add(stringConverter); messageConverters.add(new ResourceHttpMessageConverter()); messageConverters.add(new SourceHttpMessageConverter
這段代碼后面還有兩個別的處理,一次是將Jaxb放在list最后面,第二次是將一個StringConverter和一個JacksonConverter添加到list中,所以打印出converter信息中這兩個有重復的(第二次的那兩個來自springboot-autoconfigure.web,重復了不影響后面的流程)。
接著我們在自己的MVC配置類覆蓋extendMessageConverters方法,使用converter.add(xxx)加上上次自定義Java序列化的那個的和FastJson的(把自己添加的放在優先級低的位置)。最后的converters按順序展示如下(下面的已經去掉重復的StringHttpMessageConverter和MappingJackson2HttpMessageConverter,后續的相應MediaType也去重)
類名 | 支持的JavaType | 支持的MediaType |
---|---|---|
ByteArrayHttpMessageConverter | byte[] | application/octet-stream, */* |
StringHttpMessageConverter | String | text/plain, */* |
ResourceHttpMessageConverter | Resource | */* |
SourceHttpMessageConverter | Source | application/xml, text/xml, application/*+xml |
AllEncompassingFormHttpMessageConverter | Map |
application/x-www-form-urlencoded, multipart/form-data |
MappingJackson2HttpMessageConverter | Object | application/json, application/*+json |
Jaxb2RootElementHttpMessageConverter | Object | application/xml, text/xml, application/*+xml |
JavaSerializationConverter | Serializable | x-java-serialization;charset=UTF-8 |
FastJsonHttpMessageConverter | Object | */* |
這里只列出重要的兩個屬性,詳細的可以去看org.springframework.http.converter包中的代碼。
另外,基本類型都視為對應的包裝類的類型來算。還有,基本類型的json序列化就只有字面值,沒有key,不屬于規范的json序列化,但是基本上所有json框架都支持基本類型直接序列化。
好了,開始說converter的選擇邏輯。主要的代碼在org.springframework.web.servlet.mvc.method.annotation.AbstractMessageConverterMethodProcessor這個類以及它的父類中,這里根據我個人的理解簡明地說一下。
先說下寫操作的流程,也就是Http序列化?;径技性?writeWithMessageConverters 這個方法中。我們先以Accept = default(*/*)請求 http://localhost:8080/users/1 為例。
第一步是取出請求的MediaType以及我們能夠返回的MediaType,相關代碼如下:
HttpServletRequest request = inputMessage.getServletRequest(); ListrequestedMediaTypes = getAcceptableMediaTypes(request); List producibleMediaTypes = getProducibleMediaTypes(request, valueType, declaredType); if (outputValue != null && producibleMediaTypes.isEmpty()) { throw new IllegalArgumentException("No converter found for return value of type: " + valueType); }
getAcceptableMediaTypes
: 大致思路就是從Accept中獲取MediaType,這里為 [*/*] 。
getProducibleMediaTypes
: 大致思路就是根據是否支持controller方法的返回類型JavaType(這里是User類,實現了Serializable),一個個遍歷檢查配置上的所有Converter,查看他們是否支持這種Java類型的轉換,這里返回值為這里為 [application/json, application/*+json, application/json, application/x-java-serialization;charset=UTF-8, */*]。
按照Java類型規則這里應該有Jaxb2RootElementHttpMessageConverter,但是查看其源碼就知道它還需要滿足@XmlRootElement注解這個條件才行,所以這里只有上面四個MediaType,對應的三個Converter分別是Jackson、自定義的、FastJson.
第二步,把Accpet指定的MediaType具體化,意思就是req可以指定 * 這種通配符,但是服務端不應該返回帶 * 的Content-Type,代碼如下:
SetcompatibleMediaTypes = new LinkedHashSet (); for (MediaType requestedType : requestedMediaTypes) { for (MediaType producibleType : producibleMediaTypes) { if (requestedType.isCompatibleWith(producibleType)) { compatibleMediaTypes.add(getMostSpecificMediaType(requestedType, producibleType)); } } } if (compatibleMediaTypes.isEmpty()) { if (outputValue != null) { throw new HttpMediaTypeNotAcceptableException(producibleMediaTypes); } return; } List mediaTypes = new ArrayList (compatibleMediaTypes); MediaType.sortBySpecificityAndQuality(mediaTypes); MediaType selectedMediaType = null; for (MediaType mediaType : mediaTypes) { if (mediaType.isConcrete()) { selectedMediaType = mediaType; break; } else if (mediaType.equals(MediaType.ALL) || mediaType.equals(MEDIA_TYPE_APPLICATION)) { selectedMediaType = MediaType.APPLICATION_OCTET_STREAM; break; } }
第一個for循環,尋找出更具體的MediaType,isCompatibleWith方法判斷是否兼容,getMostSpecificMediaType方法取二者中更具體的那個。具體的判斷邏輯在MediaType類中,這里就不細說了,可以把更具體理解為找出 requestedMediaType 有 instanceof 關系的 producibleMediaType。因為 */* 類似于 Object 所以這里一個都篩不掉,compatibleMediaTypes最后還是那四個MediaType。
后兩行代碼是排序,按照 q值 和 具體程度 來排序。因為我們沒有指定q值,所以都是q=1。根據具體程度排序,帶 * 的會排到后面。注意那個LinkedHashSet,先來的會排在前面,加上前面的都是list迭代,所以最后的順序為[application/json, application/x-java-serialization;charset=UTF-8, application/*+json, */*]。
第二個是默認值處理,application/json 是一個具體的類型,不用再處理,所以最后的produce = application/json。
第三步,選擇一個能處理最后的produce的Converter,Jackson和FastJson都能處理,根據添加順序,此時選擇的是Jackson,也就是Jackson的優先級更高。
if (selectedMediaType != null) { selectedMediaType = selectedMediaType.removeQualityValue(); for (HttpMessageConverter> messageConverter : this.messageConverters) { if (messageConverter instanceof GenericHttpMessageConverter) { if (((GenericHttpMessageConverter) messageConverter).canWrite( declaredType, valueType, selectedMediaType)) { outputValue = (T) getAdvice().beforeBodyWrite(outputValue, returnType, selectedMediaType, (Class extends HttpMessageConverter>>) messageConverter.getClass(), inputMessage, outputMessage); if (outputValue != null) { addContentDispositionHeader(inputMessage, outputMessage); ((GenericHttpMessageConverter) messageConverter).write( outputValue, declaredType, selectedMediaType, outputMessage); if (logger.isDebugEnabled()) { logger.debug("Written [" + outputValue + "] as "" + selectedMediaType + "" using [" + messageConverter + "]"); } } return; } } else if (messageConverter.canWrite(valueType, selectedMediaType)) { outputValue = (T) getAdvice().beforeBodyWrite(outputValue, returnType, selectedMediaType, (Class extends HttpMessageConverter>>) messageConverter.getClass(), inputMessage, outputMessage); if (outputValue != null) { addContentDispositionHeader(inputMessage, outputMessage); ((HttpMessageConverter) messageConverter).write(outputValue, selectedMediaType, outputMessage); if (logger.isDebugEnabled()) { logger.debug("Written [" + outputValue + "] as "" + selectedMediaType + "" using [" + messageConverter + "]"); } } return; } } }
上面的流程解釋了為什么通過在converters末尾添加FastJsonConverter時,Fiddler的默認請求(不帶Accept或者Accept: */*),使用的是Jackson序列化,序列化了createTime字段,并且返回的 Content-Type 為application/json。
但是使用瀏覽器直接請求時,Chrome的默認請求的Accept為text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8.
根據上面的邏輯,最后的produce = text/html.
最后選擇時,只有FastJson(MediaType對應的 */*)這唯一一個converter能夠進行處理,所以用的是FastJson序列化,沒有序列化createTime字段。返回的 Content-Type 為 text/html,但是實際格式是json的。
而當使用 converters.add(0, fastJsonConverter) (或者其他等價方式)進行配置時,會把FastJsonConverter添加在最前面,優先級最高。因為FastJsonConverter的MediaType是 */*,所以它會在前面包攬所有請求的Http序列化和反序列化,就算它們不是json,也說了自己不是json、不要返回json,它還是一意孤行地當成json處理。
此時不論Accept是什么類型,返回的實際上都是FastJson序列化的json格式,但是返回的Content-Type卻還是別人
Accept 的那種類型,不一定是application/json這類json標識(掛羊頭賣狗肉)。
下面再說下讀取的流程,也就是反序列化流程,主流程在父類的 readWithMessageConverters 方法中,代碼如下:
@SuppressWarnings("unchecked") protectedObject readWithMessageConverters(HttpInputMessage inputMessage, MethodParameter parameter, Type targetType) throws IOException, HttpMediaTypeNotSupportedException, HttpMessageNotReadableException { MediaType contentType; boolean noContentType = false; try { contentType = inputMessage.getHeaders().getContentType(); } catch (InvalidMediaTypeException ex) { throw new HttpMediaTypeNotSupportedException(ex.getMessage()); } if (contentType == null) { noContentType = true; contentType = MediaType.APPLICATION_OCTET_STREAM; } Class> contextClass = (parameter != null ? parameter.getContainingClass() : null); Class targetClass = (targetType instanceof Class ? (Class ) targetType : null); if (targetClass == null) { ResolvableType resolvableType = (parameter != null ? ResolvableType.forMethodParameter(parameter) : ResolvableType.forType(targetType)); targetClass = (Class ) resolvableType.resolve(); } HttpMethod httpMethod = ((HttpRequest) inputMessage).getMethod(); Object body = NO_VALUE; try { inputMessage = new EmptyBodyCheckingHttpInputMessage(inputMessage); for (HttpMessageConverter> converter : this.messageConverters) { Class > converterType = (Class >) converter.getClass(); if (converter instanceof GenericHttpMessageConverter) { GenericHttpMessageConverter> genericConverter = (GenericHttpMessageConverter>) converter; if (genericConverter.canRead(targetType, contextClass, contentType)) { if (logger.isDebugEnabled()) { logger.debug("Read [" + targetType + "] as "" + contentType + "" with [" + converter + "]"); } if (inputMessage.getBody() != null) { inputMessage = getAdvice().beforeBodyRead(inputMessage, parameter, targetType, converterType); body = genericConverter.read(targetType, contextClass, inputMessage); body = getAdvice().afterBodyRead(body, inputMessage, parameter, targetType, converterType); } else { body = getAdvice().handleEmptyBody(null, inputMessage, parameter, targetType, converterType); } break; } } else if (targetClass != null) { if (converter.canRead(targetClass, contentType)) { if (logger.isDebugEnabled()) { logger.debug("Read [" + targetType + "] as "" + contentType + "" with [" + converter + "]"); } if (inputMessage.getBody() != null) { inputMessage = getAdvice().beforeBodyRead(inputMessage, parameter, targetType, converterType); body = ((HttpMessageConverter ) converter).read(targetClass, inputMessage); body = getAdvice().afterBodyRead(body, inputMessage, parameter, targetType, converterType); } else { body = getAdvice().handleEmptyBody(null, inputMessage, parameter, targetType, converterType); } break; } } } } catch (IOException ex) { throw new HttpMessageNotReadableException("I/O error while reading input message", ex); } if (body == NO_VALUE) { if (httpMethod == null || !SUPPORTED_METHODS.contains(httpMethod) || (noContentType && inputMessage.getBody() == null)) { return null; } throw new HttpMediaTypeNotSupportedException(contentType, this.allSupportedMediaTypes); } return body; }
因為讀取時的ContentType必定是一個具體類型(帶有 * 號會拋出異常 java.lang.IllegalArgumentException: "Content-Type" cannot contain wildcard subtype "*"),所以步驟少了一些,匹配前就一個默認值處理。
默認的請求不帶Content-Type,會進行默認值處理,最后 contentType = application/octet-stream,只有FastJsonConverter(MediaType對應的 */*)這唯一一個converter能夠進行處理,所以就沒有反序列化createTime字段,打印信息user.toString()中createTime=null。
但是當指定Content-Type: application/json時,contentType = application/json,Jackson和FastJson都能處理,按照順序,輪到Jackson反序列化,所以就反序列化了createTime字段,打印信息user.toString()中createTime不為null。
改成使用 converters.add(0, fastJsonConverter) (或者其他等價方式)進行配置時,會把FastJsonConverter添加在最前面,順序優先級比Jackson高,指定Content-Type: application/json時使用的就是FastJson來進行反序列化。
但是跟上面說的那樣,因為 */* 的原因,此時不論Content-Type是什么類型,都會是FastJsonConverter來進行反序列化操作。不過,FastJson只是個json框架,只能處理json,別的格式會拋出異常,并且還返回 HTTP 400 告訴客戶端你的請求報文格式不對(沒有金剛鉆,非要攬瓷器活,明明是自己的錯,還要說是客戶端的錯)。
好了,到此就基本上說完了整個HttpMessageConverter的匹配規則(或者叫選擇過程)。這次沒有新增代碼,也沒有演示,想要自己演示觀察的,可以在上一篇文章相關的代碼基礎上進行,如下:
https://gitee.com/page12/stud...
https://github.com/page12/stu...
最后再次吐槽下FastJsonHttpMessageConverter,作為非springmvc自帶的組件,默認設置 */* 這種MediaType,是非常不好的。上面也說了,存在掛羊頭賣狗肉、名實不副的行為,在REST已經重新引起人們對HTTP原生規范的重視的今天,這是一個很不好的做法。自己能力不是最大,卻大包大攬承擔最大責任,處理不了還返回 HTTP 400,是甩鍋客戶端的行為。阿里作為國內第一大開源陣營,其代碼設計、質量,以及開源奉獻精神還是要進一步提升啊。
自己寫代碼也要注意?。捍a中有順序遍歷匹配這種邏輯,或者叫責任鏈模式時,功能越具體的節點越是應該放在前面,功能最廣最泛的節點應該放在最后面;同時要按功能分配責任,千萬不要給功能單一的節點最大的責任(FastJsonConverter的功能單一,卻默認分配了個最大的責任 MediaType = */*)。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/68124.html
摘要:序列化反序列化主要體現在程序這個過程中,包括網絡和磁盤。如果是開發應用,一般這兩個注解對應的就是序列化和反序列化的操作。協議的處理過程,字節流內部對象,就涉及這兩種序列化。進行第二步操作,也就是序列化和反序列化的核心是。 以下內容,如有問題,煩請指出,謝謝! 對象的序列化/反序列化大家應該都比較熟悉:序列化就是將object轉化為可以傳輸的二進制,反序列化就是將二進制轉化為程序內部的...
摘要:簡介注解用于修飾的方法,根據的的內容,通過適當的轉換為客戶端需要格式的數據并且寫入到的數據區,從而不通過視圖解析器直接將數據響應給客戶端。并且這些解析器都實現了接口,在接口中有四個最為主要的接口方法。 SpringMVC 細節方面的東西很多,所以在這里做一篇簡單的 SpringMVC 的筆記記錄,方便以后查看。 Spring MVC是當前最優秀的MVC框架,自從Spring 2.5版本...
摘要:環境要求使用純來搭建環境,要求的版本必須在以上。即視圖解析器解析文件上傳等等,如果都不需要配置的話,這樣就可以了??梢詫⒁粋€字符串轉為對象,也可以將一個對象轉為字符串,實際上它的底層還是依賴于具體的庫。中,默認提供了和的,分別是和。 在 Spring Boot 項目中,正常來說是不存在 XML 配置,這是因為 Spring Boot 不推薦使用 XML ,注意,并非不支持,Spring...
摘要:關鍵注解的關鍵注解主要有其中主要是用于標記該類是一個控制器,用于指示的哪一個類或方法來處理請求動作,即用于標識具體的處理器。默認已經裝配了作為組件的實現類,而由使用,將請求信息轉換為對象。 關鍵注解 springmvc的關鍵注解主要有@Controller/@RequestMapping/@RequestParam/@PathVariable/@RequestHeader/@Cooki...
摘要:分發處理器將會掃描使用了該注解的類的方法,并檢測該方法是否使用了注解。的作用相當于,只不過按照自動注入。作用該注解用于將的方法返回的對象,通過適當的轉換為指定格式后,寫入到對象的數據區。用于注解層,在類上面注解。 原文地址 Controller 在SpringMVC中,控制器Controller負責處理由DispatcherServlet分發的請求,它把用戶請求的數據經過業務處理層處理...
閱讀 2348·2021-11-15 11:37
閱讀 2625·2021-09-23 11:21
閱讀 2951·2021-09-07 10:11
閱讀 3164·2019-08-30 15:53
閱讀 2826·2019-08-29 15:13
閱讀 1606·2019-08-26 13:57
閱讀 1098·2019-08-26 12:23
閱讀 2438·2019-08-26 11:51