OkHttpClient对接WebSphere Liberty双向gzip压缩配置及有效性验证问题

问题a：无抓包场景下验证压缩生效的方法 #

• 验证客户端请求压缩：
  1. 给OkHttp添加内置的HttpLoggingInterceptor，设置日志级别为BODY，直接打印所有发出请求的头信息，若看到Content-Encoding: gzip说明头已正确添加；同时对比日志中打印的请求体原始大小和实际发送的字节数，压缩后字节数会远小于原始JSON大小。
  2. 在WebSphere Liberty侧开启访问日志，在server.xml的httpEndpoint节点下添加accessLogging配置，可直接打印所有入站请求的头属性、入站字节数，若日志中存在Content-Encoding: gzip且入站字节数远小于你发送的原始JSON体积，即可确认请求压缩生效。
  3. 也可以在你自定义的CompressionInterceptor的gzip方法中添加临时日志，分别统计原始RequestBody的长度和压缩后写入sink的字节数，对比即可验证压缩逻辑是否执行。
• 验证服务端响应压缩：
  直接在业务代码中打印返回Response的头信息，若存在Content-Encoding: gzip，即可确认服务端返回了压缩后的响应。

问题b：双向压缩实现情况校验 #

1. 客户端→服务端的请求压缩：
   你当前的拦截器逻辑仅对携带请求体的请求（也就是你的POST请求）执行压缩，GET请求本身无请求体不需要压缩，这部分逻辑是正确的。服务端Liberty默认支持gzip编码的请求自动解压，你配置的压缩规则也兼容gzip编码的入站请求，所以POST请求的压缩已经实现。
2. 服务端→客户端的响应压缩：
   要实现响应压缩需要客户端主动告知服务端支持gzip编码，也就是请求头需要携带Accept-Encoding: gzip。你当前的代码中没有显式添加这个头，OkHttp默认开启的透明gzip虽然会自动添加该头并自动解压响应，但为了避免自定义拦截器覆盖默认逻辑，建议你在构建所有请求时统一添加addHeader("Accept-Encoding", "gzip")头。
   确认方式就是前面提到的打印响应头的Content-Encoding字段，只要返回值为gzip，说明响应压缩已经生效。

另外补充一个小优化点：你当前的服务端配置已经覆盖了application/json类型的返回值压缩，不需要额外调整规则。

内容的提问来源于stack exchange，提问作者Doug