记一次前后端联调返回数据超时的问题

背景：子系统返回下载链接后上层系统会将下载链接进行转换成特殊下载链接，可是前端始终是接收不到返回值

原因，上层系统做处理的时候相当于做请求拦截，将子系统请求结果拦截到之后做参数转换，由于返回结果变动了，导致原来的content-length和现在接到的结果长度不一致，浏览器判断出前后不一致，如果超过长度就会进行截断，如果不及长度就会等待直到超时。。。。

3.http协议之Content-Length

对于http的请求返回结果要进行内容的长度校验主要有两种方式，二者互斥使用：

1.客户端在http头(head)加Connection:keep-alive时，服务器的response是Transfer-Encoding:chunked的形式，通知页面数据是否接收完毕，例如长连接或者程序运行中可以动态的输出内容，例如一些运算比较复杂且需要用户及时的得到最新结果，那就采用chunked编码将内容分块输出。

2.除了如1所述之外的情况一般都是可以获取到Content-Length的。

在具体的HTTP交互中，客户端是如何获取消息长度的呢，主要基于以下几个规则：

1、Content-Length如果存在并且有效的话，则必须和消息内容的传输长度完全一致。（经过测试，如果过短则会截断，过长则会导致超时。）

2、如果存在Transfer-Encoding（重点是chunked），则在header中不能有Content-Length，有也会被忽视。

3、如果采用短连接，则直接可以通过服务器关闭连接来确定消息的传输长度。（这个很容易懂）

结合HTTP协议其他的特点，比如说Http1.1之前的不支持keep alive。那么可以得出以下结论：

1、在Http 1.0及之前版本中，content-length字段可有可无。

2、在http1.1及之后版本。如果是keep alive，则content-length和chunk必然是二选一。若是非keep alive，则和http1.0一样。content-length可有可无