借助302转发规避长耗时接口的连接超时问题

借助302转发规避长耗时接口的连接超时问题

问题描述

常规HTTP请求有连接时长限制, 一般为120s, 依赖于服务器(含中间件)和客户端配置。对于某个特定的任务时长可能很长的接口来说， 120s可能无法满足需要， 此时请求会被主动断开， 请求方收到连接超时或其他异常。且此种情况下，即使服务端正常结束了该长耗时任务，任务结果也无法下发给客户端。

一种比较简单的处理方式是， 接口收到该任务时，生成一个任务id，启动任务，并立即将任务id发送给客户端；客户端采用轮询方式使用任务id到服务器调用另外一个接口获取任务进度 或/和 任务结果。这种方案设计到客户端和服务端的两端配合改造。

本文提供另外一个思路，将上述思路进一步优化, 避免客户端的改造（服务端仍然需要改造）。

解决思路

服务端将一个长耗时任务拆分成1+N个短的连接请求，通过302跳转告知客户端下一个请求的地址，客户端通过新地址查询任务结果。

由于302转发一般是浏览器内部处理，并不需要暴漏到js代码层面处理，客户端请求此类接口和请求常规接口在调用上没有任何区别。所有的区别在fetch内部处理掉了。

客户端改造

无需改造, 正常发送fetch请求即可(POST/GET均可以)

服务端改造

• 长耗时任务不需要返回taskid, 如果50s仍未结束, 统一让客户端跳转至 /xxxx/api/long_task/:task_id?t=时间戳 这个地址,
• 实现一个接口, /xxxx/api/long_task/:task_id 实现根据task_id查询结果, 如果任务已结束, 直接返回内容;未结束,则等待50s仍未结束的话, 发下一个302跳转, 直至任务结束

总结

结合任务id的思想, 经过改造, 客户端发送的一个POST请求会被服务器拆解为 1个POST请求+N个GET请求, N大于等于0;
这1+N个请求被浏览器的fetch内部屏蔽,js层面认为只发送并接收了一个POST请求, 进而实现了客户端代码的0改造.