由一个序列化框架的更换引发的问题

问题背景

项目使用SpringMVC4.1.X作为web框架，序列化框架选择Jackson。出于使用习惯以及性能考虑，将其切换到了fastjson。配置如下：

<mvc:annotation-driven>
        <mvc:message-converters register-defaults="true">
            <!-- 避免IE执行AJAX时,返回JSON出现下载文件 -->
            <bean id="fastJsonHttpMessageConverter" class="com.alibaba.fastjson.support.spring.FastJsonHttpMessageConverter">
                <property name="supportedMediaTypes">
                    <list>
                        <value>application/json;charset=UTF-8</value>
                        <value>text/html;charset=UTF-8</value>
                        <value>application/x-www-form-urlencoded;charset=UTF-8</value>
                    </list>
                </property>
                <property name="features">
                    <list>
                        <value>WriteMapNullValue</value>
                        <value>WriteNullStringAsEmpty</value>
                        <value>WriteNullListAsEmpty</value>
                        <value>WriteNullNumberAsZero</value>
                    </list>
                </property>
            </bean>
        </mvc:message-converters>
    </mvc:annotation-driven>

　

问题表现

如上配置后，一段时间后，线上出现故障。对接方反馈其请求成功，但是解析响应报文失败。故障表现如下：

如上所示，响应的Content-Type为表单。对接方说之前是application/json。乍看之下有点蒙，更改一个序列化框架会导致响应Content-Type发生变化。

问题原因

仔细看了下其请求header，发觉了有点不太对的地方。其请求的Accpet是application/x-www-form-urlencoded，那我响应的Content-Type是这个就没有问题才对。但之前说这样的请求我们响应的是application/json，那回过头去看之前的配置如下：

<bean id="contentNegotiationManager" class="org.springframework.web.accept.ContentNegotiationManagerFactoryBean">
        <!-- 扩展名至mimeType的映射,即 /user.json => application/json -->
        <property name="favorPathExtension" value="true"/>
        <!-- 用于开启 /userinfo/123?format=json 的支持 -->
        <property name="favorParameter" value="true"/>
        <property name="parameterName" value="format"/>
        <!-- 是否忽略Accept Header -->
        <property name="ignoreAcceptHeader" value="false"/>
        <property name="mediaTypes"> <!--扩展名到MIME的映射；favorPathExtension, favorParameter是true时起作用  -->
            <value>
                json=application/json
            </value>
        </property>
    </bean>

    <bean class="org.springframework.web.servlet.view.ContentNegotiatingViewResolver" p:order="0">
        <!-- 内容协商管理器 用于决定media type -->
        <property name="contentNegotiationManager" ref="contentNegotiationManager"/>
        <!-- 默认视图 放在解析链最后 -->
        <property name="defaultViews">
            <list>
                <bean class="org.springframework.web.servlet.view.json.MappingJackson2JsonView"/>
            </list>
        </property>
    </bean>

之前的配置是基于Spring的内容协商机制来实现内容响应控制。按上述配置，会组装出基于一组基于：

• 路径扩展
• 参数扩展
• accept

的内容协商策略。这组策略会按照上述顺序解析请求的媒体类型，如果某个策略可以识别请求的媒体类型，则不再继续后续的识别。如下ContentNegotiationManager代码：

    public List<MediaType> resolveMediaTypes(NativeWebRequest webRequest) throws HttpMediaTypeNotAcceptableException {
        for (ContentNegotiationStrategy strategy : this.contentNegotiationStrategies) {
            List<MediaType> mediaTypes = strategy.resolveMediaTypes(webRequest);
            if (mediaTypes.isEmpty() || mediaTypes.equals(MEDIA_TYPE_ALL)) {
                continue;
            }
            return mediaTypes;
        }
        return Collections.emptyList();
    }

那么为啥之前的配置可以在客户端的accept设置为application/x-www-form-urlencoded时仍然可以返回application/json呢？缘由在于请求参数有一个format=json，匹配了这里的参数扩展策略以及对应的媒体类型mediaTypes中的key。

去掉内容协商后，就从请求header中读取accept来确认响应content-type。

后面调整的配置指定了FastJsonHttpMessageConverter作为第一个转换器。设置其支持的转换媒体类型有：

• application/json;charset=UTF-8

• text/html;charset=UTF-8

• application/x-www-form-urlencoded;charset=UTF-8

其中就有application/x-www-form-urlencoded;charset=UTF-8这种媒体类型。当前端的header中指定accept的类型为此时，后端响应请求做消息转换时，会match消息转换器配置的支持类型与前端要求的响应类型，寻找交集。很不幸的是application/x-www-form-urlencoded;charset=UTF-8正好能匹配，故此时通过FastJsonHttpMessageConverter返回json的数据，然后content-type是application/x-www-form-urlencoded;charset=UTF-8。

这块的逻辑在SpringMVC的AbstractMessageConverterMethodProcessor如下片段：

        HttpServletRequest servletRequest = inputMessage.getServletRequest();
        List<MediaType> requestedMediaTypes = getAcceptableMediaTypes(servletRequest);
        List<MediaType> producibleMediaTypes = getProducibleMediaTypes(servletRequest, returnValueClass);

        Set<MediaType> compatibleMediaTypes = new LinkedHashSet<MediaType>();
        for (MediaType r : requestedMediaTypes) {
            for (MediaType p : producibleMediaTypes) {
                if (r.isCompatibleWith(p)) {
                    compatibleMediaTypes.add(getMostSpecificMediaType(r, p));
                }
            }
        }
        if (compatibleMediaTypes.isEmpty()) {
            throw new HttpMediaTypeNotAcceptableException(producibleMediaTypes);
        }

        List<MediaType> mediaTypes = new ArrayList<MediaType>(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;
            }
        }

        if (selectedMediaType != null) {
            selectedMediaType = selectedMediaType.removeQualityValue();
            for (HttpMessageConverter<?> messageConverter : messageConverters) {
                if (messageConverter.canWrite(returnValueClass, selectedMediaType)) {
                    ((HttpMessageConverter<T>) messageConverter).write(returnValue, selectedMediaType, outputMessage);
                    if (logger.isDebugEnabled()) {
                        logger.debug("Written [" + returnValue + "] as "" + selectedMediaType + "" using [" +
                                messageConverter + "]");
                    }
                    return;
                }
            }
        }

解决方案

如上所述，根本问题是后端响应的content-type设置有一个优先级顺序。优先基于后端策略控制来处理，然后基于前端的请求header的accept来控制。那去掉后端的内容决策逻辑后，响应内容就依赖前端的accpet。故存在响应的content-type是application/x-www-form-urlencoded;的情况。

解决方案有2种方式：

1. 客户端的声明需要内容时，accept设置正确；
2. 服务端使用内容决策策略来控制响应格式时，客户端的accpet也不可以随便处理，虽然优先级不一样，但是以防万一调整导致未知失败。