记录BUG记录美好生活

BUG表现方式

昨天因为公司写的.NET WEB API 项目在两台服务器上部署，其中部署在A服务器运行一切正常，而部署在B服务器则出现登陆信息丢失的问题。

BUG查找

我根据两台服务器部署的前端来进行检测，查看是否有什么不同，后来发现登陆成功之后是在响应头上两台服务器都返回了用于验证身份信息的.ASPXAUTH的Cookie，再往下查我在浏览器(谷歌)Application-Storage-Cookies里面查看浏览器是否真的记录了.ASPXAUTH的Cookie，发现果然A服务器是存在的，B服务器没有；在得出此结论之后的我又陷入了沉思…

1. 在此次代码版本更新中我只给验证身份信息的Cookie增加了一个过期时间；
2. 同一套后台代码部署在两个服务器；
3. 是什么原因让A服务器部署的前端浏览器能正常保存Cookie，而B服务器不行
4. 既然都是同一套代码，不是后端的问题，应该也不是前端的问题吧，难道是运维部署的时候配置没有配对？（我赶紧让运维去检查后端的web.config）

针对上面提出的问题我与运维分头行动，在经过几分钟的查找问题之后，我去对比了两个服务器后端登陆接口返回的响应头终于有所发现：

1. 两个服务器后端返回的响应头Date时间不对，A服务器返回的响应头Date会随着A服务器的系统时间所变动；B服务器后端返回的Date是不变的，固定在某一时间；
2. 到这里真正导致B服务器登陆信息丢失的问题已经找到：
   这个Date响应头是跟Cookie的过期时间有着很大关系的。因为我后端设置的Cookie是有过期时间的，因为A服务器后端返回的响应头是正常的，所以A服务器并没有问题；而B服务器返回的时间永远定格在某个时间段（这个时间段永远大于我的Cookie的过期时间），所以导致我B服务器返回来的Cookie永远是过期的，进而导致了BUG的产生

BUG进阶

是什么原因导致了B服务器后端返回的响应头Date的时间永远不变呢？

面对这问题，我苦苦思索，思索是否是代码的问题，后端？不可能。前端？更不可能。
那剩下唯一可能改变响应头Date就是IIS服务器了。我果断上B服务器的IIS上看了看，然而并没有什么地方写死了Date响应头。于是我又陷入了沉思…

在经过一段时间的翻阅资料终于有所发现：

1. 由于IIS服务器的时间同步功能的BUG，并且在虚拟机上经常发现。
2. 将系统时间更改为将来的时间（例如2020年5月11日）
3. 浏览任何站点-验证在新日期/时间创建的日志文件
4. 将系统时间更改为正确的（今天的日期和时间）
5. 现在，浏览任何网站，发现日志文件上的时间现在停留在2020年5月11日

BUG解决方法

• net stop http 停止HTTP服务
• net start http 启动HTTP服务
• iisreset 重启IIS服务器

最后献上我参考的文章：https://serverfault.com/questions/217343/date-header-returned-by-iis7-is-wrong