记一次线上bug排查-----SpringCloud Gateway组件请求头accept-encoding导致响应结果乱码

news/2023/12/5 23:19:15

基于公司的业务需求，在SpringCloud Gateway组件的基础上，写了一个转发服务，测试开发阶段运行正常，并实现初步使用。但三个月后，PostMan请求接口，返回异常，经排查，从日志中获取到转发响应的结果为乱码：

跟踪日志：

转发到目标接口，响应结果已乱码。一般排查的思路是，查看请求方和响应方的编码格式是否一致，打印请求方的编码格式为UTF-8,响应服务的编码格式也是UTF-8。

以上说明编码格式没有问题。上网去找“gateway响应结果乱码”的相关文章，大多数会提供解决方案：

DataBufferFactory dataBufferFactory = new DefaultDataBufferFactory();
DataBuffer join = dataBufferFactory.join(dataBuffers);
byte[] content = new byte[join.readableByteCount()];
join.read(content);
// 释放掉内存
DataBufferUtils.release(join);
String str = new String(content, Charset.forName("UTF-8"));
originalResponse.getHeaders().setContentLength(str.getBytes().length);
System.out.println(str);
return bufferFactory.wrap(str.getBytes());

这段关键代码，在我的响应结果包装过滤器是有的，如下：

    /*** 获取到解码方的response,验签--->重新封装--->加签* 通过 DataBufferFactory 解决响应体分段传输问题。*/private ServerHttpResponseDecorator verifyRePackageSignatureResponse(ServerWebExchange exchange, String jmf_decode_url, String route_privateKey, String jmf_publicKey) {ServerHttpResponse response = exchange.getResponse();log.debug("R:给响应结果response设置编码格式----START----");response.getHeaders().add("Content-Type","application/json;charset=UTF-8");log.debug("R:给响应结果response设置编码格式-----END-----");DataBufferFactory bufferFactory = response.bufferFactory();return new ServerHttpResponseDecorator(response) {@Overridepublic Mono<Void> writeWith(Publisher<? extends DataBuffer> body) {if (body instanceof Flux) {// 获取响应类型，如果是 json 就打印String originalResponseContentType = exchange.getAttribute(ServerWebExchangeUtils.ORIGINAL_RESPONSE_CONTENT_TYPE_ATTR);log.debug("响应类型为originalResponseContentType:{}",originalResponseContentType);if (RequestResponseUtil.isJson(originalResponseContentType)) {Flux<? extends DataBuffer> fluxBody = Flux.from(body);return super.writeWith(fluxBody.buffer().map(dataBuffers -> {// 合并多个流集合，解决返回体分段传输DataBufferFactory dataBufferFactory = new DefaultDataBufferFactory();DataBuffer join = dataBufferFactory.join(dataBuffers);byte[] content = new byte[join.readableByteCount()];join.read(content);// 释放掉内存DataBufferUtils.release(join);// 正常返回的数据String rootData = new String(content, StandardCharsets.UTF_8);log.debug("R:正常返回的数据rootData为:{}", rootData);//使用枚举 + 工厂 + 策略模式（第二版）String newQqtBodyJson = null;try {newQqtBodyJson = DecoderSignStrategyContext.zwmVerifySignResponse(rootData, jmf_decode_url, route_privateKey, jmf_publicKey);log.debug("R:【码路由服务】经具体策略处理，得到结果newQqtBodyJson为:{}", newQqtBodyJson);} catch (Exception e) {log.error("R:【码路由服务】解码方返回结果验签异常:{}", e);throw new VerifySignException(StaticVar.FAIL_10020015, "R:【码路由服务】解码方返回结果验签异常");}byte[] respData = newQqtBodyJson.getBytes();//byte[] respData = newQqtBodyJson.getBytes(StandardCharsets.UTF_8);byte[] uppedContent = new String(respData, Charset.forName("UTF-8")).getBytes();return bufferFactory.wrap(uppedContent);}));} else {log.error("响应结果异常");throw new ProcessHandleException(StaticVar.FAIL_10020015, "R:【码路由服务】解码方返回结果异常,非法JSON");}}// if body is not a flux. never got there.return super.writeWith(body);}};}

因此不是代码的问题。又找到了一篇文章，解决了PostMan请求的问题。

https://bbs.csdn.net/topics/399102026/close

如上所述，在PostMan请求的headers中去掉Accept-Encoding,请求成功：

至此，PostMan请求乱码的问题已解决。但事情似乎没有那么简单，接下来，使用手机模拟扫码，请求码路由服务，又出现了乱码，扫码结果页面，返回结果:

查看日志，乱码如下：

排查问题进入瓶颈期，有些烦躁了，必须冷静下来，重新捋一下代码，同时也在想，既然和PostMan请求存在同样的问题，是不是在请求头中默认会有一个Accept-Encoding属性，从而导致了乱码，根据这个思路，在自定义的请求转发过滤器中，发现了以下代码：

由于在请求转发的逻辑中，重新构建了一个request请求的同时，重新创建了一个请求头headers,它在重新构建的时候默认会有一个accept-encoding属性，看到这一行代码时，正印证了以上我的猜想，问题已经找到了，将其置为空字符串即可（注意：不能使其为null,也不能remove这个属性，会报错）。

将headers的accept-encoding属性置为空字符串，并添加注释如下：

// 定义新的消息头HttpHeaders headers = new HttpHeaders();//System.out.println("headers = " + headers); //查看重新定义消息头的内容headers.putAll(exchange.getRequest().getHeaders());// 由于修改了传递参数，需要重新设置CONTENT_LENGTH，长度是字节长度，不是字符串长度int length = bodyStr.getBytes().length;log.debug("bodyStr长度为:{}",length);headers.remove(HttpHeaders.CONTENT_LENGTH);// 设置CONTENT_TYPEif (StringUtils.isNotBlank(contentType)) {headers.set(HttpHeaders.CONTENT_TYPE, contentType);}String jmf_decode_url = request.getURI().toString();String qqtBodyJsonStr = JSONUtils.toString(bizPackage);//request.mutate().header(HttpHeaders.CONTENT_LENGTH, Integer.toString(bodyStr.length())); //报错JSON parse error JsonEOFException，长度必须为字节的长度request.mutate().header(HttpHeaders.CONTENT_LENGTH, Integer.toString(length));//成功，解决JSON parse error JsonEOFException/*** 乱码现象：请求响应结果乱码* 解决过程分为PostMan请求和手机端App扫码请求：*   （1）、PostMan请求响应乱码解决：*             PostMan请求的headers中默认会有"Accept-Encoding"属性，值为"gzip, deflate, br",导致响应结果乱码*         去掉Accept-Encoding后请求正常。**   （2）、手机端App扫码请求乱码解决：*             在HttpRequestSignForwardGatewayFilter中定义新的消息头，headers中默认会有"accept-encoding"属性，*         值为"gzip, deflate, br", 添加代码"request.mutate().header("accept-encoding",""); "解决乱码**       注意: 创建headers对象默认会生成“accept-encoding=‘gzip, deflate, br‘ ”属性，此处必须将accept-encoding*       置为空字符串（置为null会报错），否则使用默认值会导致响应结果乱码。*       说明: 测试开发阶段未发生此问题，第三方检测时演示出现此问题，这个可能是gateway内部的问题，尚未可知。**          经测试，这种方式已解决了：手机端APP扫码和PostMan响应结果乱码的问题（PostMan请求时可以不用刻意去掉Accept-Encoding，*       也可请求成功）**/request.mutate().header("accept-encoding","");

重启后，部署后问题得到解决。这个问题在测试开发阶段没有暴露出来，按理说应该早暴露了，但现实情况就是这么诡异，这可能是Gateway内部的bug，尚未可知。