近日服务端新上线了新的防盗链机制，之后接收到个别用户的反馈问题，下载文件时无法通过防盗链校验。具体的校验方式就不多谈了，只说经过排查，服务端给客户端这边的反馈是客户端发送的UA不对。
于是联系了一个反馈的用户看了一下，服务端说UA不对那就抓包看一下嘛。装上Fiddler，一看发的包UA是正确的。莫非抓包工具有问题？换上Wireshark，再看抓到的包，然而还是没有发现数据有异常。但是服务端的人还是说，打出来的UserAgent是不对的，字符串的最后被截断了，少了十几个字符。
从用户处又得到另外一个线索，如果连接WIFI会出现问题，而如果连接手机发射的移动热点，则一切正常。又把问题指向了网络环境。
既然在电脑上抓到的包与服务端收到的包不一样，那大概就是用户的网络环境有一些神奇的问题了。但是按照这个思路看的话，应该其他任意客户端都会遇到一样的问题。然而开了个IE，直接往接口发请求，收到的数据是正常的。这回真是十分尴尬，想说不是客户端的问题都拿不出证据了，为什么其他程序就正常运行。
毕竟HTTP只是个文本协议，没有很多花里胡哨的东西，肯定也没办法识别出发送的程序进行针对性处理，肯定还是请求内容导致的。分别抓一个正常请求与不正常请求进行对比，发现请求内容确实是有区别的。
业务接口用户量大，直接在业务接口上进行测试的话日志量会很多，不利于观察，也影响其他用户。于是另开了个测试接口，将所有访问请求的UA都打出来。直接给用户发了个curl.exe，用curl直接分别发两个请求内容的包，进一步确认了是请求内容的细微差异导致了数据在网络上会被篡改。于是接下来就简单了，逐个字段互换排查，最终发现导致问题的关键区别是，正常请求中的HTTP Header中有Accept-Encoding字段，如果不带Accept-Encoding字段，请求到达服务端的时候UserAgent字段就会被截断最后一部分。
接到反馈的两个用户都是使用的斐讯路由器，基本上可以确定是路由器导致了这样的行为。UserAgent字段只是一个标识，一般也不会有刻意修改的必要。截断的行为基本是按照一个固定的长度截的，只能理解为路由器的一个Bug吧。
在网上搜了一圈也没搜到相关的东西，不过这个问题确实一般也不会发现，如果不是服务端这次升级了校验机制，可能这个问题永远都不会有人发现吧。如果有遇到相同问题的人，看到这篇不如留个名~
