继承了HttpServletResponseWrapper的HttpServletResponse包装类响应不全/缺失的问题

 

今天使用SpringBoot开发时遇到了一个奇怪的问题,在过滤器的doFilter方法里对rapperServletResponse的getResponseData进行修改后(添加某字段)重新写入,在postman上就读不全了,总是少一截.都不是合格的json了.

doFilter中相关代码如下:

WrapperedRequest wrapRequest = new WrapperedRequest((HttpServletRequest) request, requestJson.toString());
WrapperedResponse wrapResponse = new WrapperedResponse((HttpServletResponse) response);
chain.doFilter(wrapRequest, wrapResponse);
byte[] data = wrapResponse.getResponseData();
String responseData = new String(data, "utf-8");
log.info("原始返回数据： " + responseData);
JSONObject responseJson = JSONObject.parseObject(responseData);
responseJson.put("traceId", traceId);
log.info("添加traceId后原始返回数据:" + responseJson.toJSONString());
writeResponse(response, responseJson.toString());

writeResponse方法如下:

private void writeResponse(ServletResponse response, String responseString) throws IOException {
    log.info("向ServletResponse写入内容:" +  responseString);
    response.setContentLength(-1);
    PrintWriter out = response.getWriter();
    out.write(responseString);
    out.flush();
    out.close();
}

使用postman测试时,就会出现返回报文不全的情况:

例如控制台打印输出为:

{"traceId":"123451234512345","code":"00","data":{"traceId":"123451234512345","date":"20190415","time":"201112"}}

但postman读取到的,却是:

{"traceId":"123451234512345","code":"00","data":{"traceId":"123451234512345","date":"

 这个问题非常奇怪,连搜都不知道怎么搜,偶然看到了这篇文章 https://blog.csdn.net/qq_33206732/article/details/78623042

尝试了一下这个参数,问题得以解决:

//向response写入修改后的返回内容之前,将contentLength重置,避免客户端读取响应不全的问题
response.setContentLength(-1);

具体原因请参考文章: https://www.cnblogs.com/xingele0917/p/3673877.html

有可能在运行的过程中页面只输出一部分，尤其是在使用多个框架后(比如sitemesh)出现的可能性非常大，在探究了好久之后终于发现原来是响应的ContentLength惹的祸。因为在经过多个过滤器或是框架处理后，很有可能在其他框架中设置了响应的输出内容的长度，导致浏览器只根据得到的长度头来显示部分内容。知道了原因，处理起来就比较方便了，我们在处理结果输出前重置一下ContentLength即可

回到我遇到的这个问题(以下为我的猜想,更严谨的内容有待仔细研究)

由于这一句导致修改后的响应内容长度length2大于原响应内容长度length1,但writeResponse不会修改response的contentLength.因此postman按照length1去读取长度为length2的响应时,就会出现响应数据读取不全的情况.

responseJson.put("traceId", traceId);

再次感谢文中两处文章的作者!

https://blog.csdn.net/qq_33206732/article/details/78623042

https://www.cnblogs.com/xingele0917/p/3673877.html