线上问题处理1

问题描述：直接调用接入方原始接口是可以顺利调用的，但是走中枢系统以后就报错。

 

 

 

 

 

 排错过程：

1. 刚开始看见gzip以为是文件压缩的错误，所以通过原接口返回值去确认是否有文件信息的字段，发现原接口返回值就是很正常的json数据，所以这一步可以排除；

2. 然后通过各种百度发现http协议里面的Headers中Accept-Encoding包含gzip，就查询Accept-Encoding的资料，通过一番基本确定是request时Headers中的Accept-Encoding和response时Headers中的Content-Encoding从中作祟。但是通过原接口和中枢接口两种方式的对比发现这两个header头值都是一样的，所以这一步时又卡住进行不下去了。

 

 

 3. 走postman看不出来问题就在线上打断点看中枢传递给原接口的东西到底是什么，然后发现中枢传递的数据也很正常，而且中枢一万多条API都没问题(同时也找了一个正常访问的接口同样打了断点看过)，偏偏这一个接口有问题，其实这时已经怀疑是原接口做什么处理了，让他们自己去查询，得到的回复是他们没做任何处理，。。。好吧，不到黄河不死心，那就给你找真正的问题。一步步的跟源码，最后找到了报错的位置。

 

 4. 第三步虽然找到了报错位置，但是没有找到报错原因，但是通过跟踪源码也确定了之前的猜测的确是对的，服务端告诉客户端我是用gzip压缩的内容，客户端需要用gzip格式去解压缩，但是解压的时候内容又不是gzip压缩的，所以解压失败报了如上错误。看了源码它是对前两个字节进行操作后与gzip的一个魔数进行比较，现在就是这一步错误，通过断点得出的61215进行十六进制编码后发现是 ef1f ，而代码中内置的 GZIP_MAGIC = 0x8b1f，现在综合Accept-Encoding，Content-Encoding这两个头信息的值其实已经确定是接入方原接口错误了，因为内容是他们返回来的。。。但是还是要给它们提供证据让他们死心，不然他们不查帅锅给我们

5. 走断点其实也看不出来我们这边到底是发的什么给原接口，当时又不想用抓包工具，就找了个笨办法，把原接口的地址改成网上的一个万能调试地址 http://httpbin.org/ 。使用了其中的一个/anything接口（传递什么过去它响应什么回来），看下我们这边到底传递了什么。。。。然后把这个返回内容放到postman去请求，发现不通了。。好吧，问题是我们这边的，经过仔细对比，我们这边传递时header多了一个authorization头信息(中枢所有接口都携带了这个字段，具体原因不清楚。。。)

6. 通过第五步其实已经确定是我们这边多传递东西了，但是我们是平台，接入方要适应我们这边，所以还是告诉他们让他们去做兼容，但是当时还是好奇他们返回的东西到底是不是gzip压缩，所以用抓包工具抓到响应内容，发现响应内容的前两个字节的确是1fef，与断点时读取出来的前两个字节31，239匹配了。此时代码断点和抓包也对应上了，基本定位到问题了