请求头中的Cache Control参数引出的一个Bug

最近手头上接了一个App,主要是进行维护与修复Bug.说实话,这种活最累的,查找一个他人写的逻辑或者页面,经常半天就过去.
而且上线的时候居然有有个非常严重的Bug没有修复,哎,只好硬着头皮搬砖.

bug是这样的:
手机密码找回,需要调用一个接口,入参是手机号,然后请求后,返回一个验证码.
很简单的需求,一般App的找回密码也基本是这样一个逻辑.
结果,问题来了,同一个手机号码,安卓这边,每次请求后,都会返回验证码.而iOS这边,第一次请求成功后,返回了验证码,之后再怎么请求,都不会返回验证码了,而且跟踪后台的响应,每次都是成功的.

我和安卓的兄弟,对了入参,这是一个get请求,只需要将手机号拼接到api后面即可,入参一致,pass.
而后,我们对了请求头,请求头中的Map的key与value拼写无误,类型无误,但是,不管怎么样,iOS这边就是每次请求都成功,然而没有验证码.

之后,我在对比每次服务器返回的响应体的时候发现了问题:每次返回的响应时间都是一样的,而且都是第一次请求成功返回了验证码的时间,Date每次都是相同的.

{
    "Cache-Control" = "max-age=259200";
    Connection = "keep-alive";
    "Content-Type" = "application/json";
    Date = "Mon, 05 Aug 2019 08:19:53 GMT";
    Expires = "Thu, 08 Aug 2019 08:19:53 GMT";
    Server = "nginx/1.10.3 (Ubuntu)";
    "Transfer-Encoding" = Identity;
    "X-Application-Context" = "??APP:uat-product,swagger:9800";
}

也就是说,一旦我请求成功,获取到了验证码之后,之后每次请求该接口后台都是返回的该接口最近一次的成功缓存.
短信接口本质上是App请求后台,后台去请求专门的短信服务商接口.

本质是我的参数透传到短信服务商的接口上.另外为何同样的请求参数与请求头,安卓这边没有问题,而iOS这边就有问题呢?
为了方便模拟测试接口,我和后台的兄弟通过postman进行该接口的调试,发现每次都能请求成功,而且获取到验证码,而且响应体返回的响应时间也是实时的.
最后我们发现,postman每次请求的时候,都会在请求头中带一个我们两端都没有带的参数{"Cache Control": "no-cache"}.
于是抱着死马当活马医的想法,我在iOS端的请求头中添加了该请求头参数,果然就好了.
但是为何安卓端不用带就是好的呢?后台的兄弟说是安卓这边的安全级别要低一些,我也不知道是什么回事.

总结:
短信平台中对于过于频繁的请求短信接口应该是会有一个判断的,而读取成功的缓存也应该是有一个时限性,不知道为何在iOS这边的请求过去的时候,就变成了长期读取缓存而不进行真正的请求,通过这个请求参数可以忽略掉读取缓存进行请求.

相关链接