有两个应用程序 A 和 B。
A用于验证用户身份并将token传递给B，B添加cookie。
每当 cookie 过期或经过很长一段时间或硬浏览器重置后，就会发生奇怪的情况。
没有提琴手：
用户点击应用程序 A 输入凭据并转发到应用程序 B。立即，三秒钟内，浏览器会显示黑色的“xxx 响应时间太长”错误屏幕，然后默认页面“就地”呈现并替换不久之后出现错误屏幕。当 cookie 过期或经过很长一段时间后，就会发生这种情况。
与 Fiddler 一起：（参见第 61、71 和 83 节）
当我在 fiddler 中执行相同的场景时，我希望看到黑色的“xxx 响应时间太长”屏幕，我得到了带有打开锁定图标的证书错误屏幕。我三次都驳回了这一点。当我忽略 ssl 隧道错误时，默认用户页面正在呈现。
相关性大约是在小提琴中的锁定对话框与我得到黑色浏览器错误屏幕的同一位置，并且应用程序似乎正在后台加载，然后在完全加载后刷新。
我的想法是，有一个 https-->http 请求被 A-->B“部分”阻止，因为 B 只是 http，没有证书。开发人员告诉我他们找不到 https 发出的请求。
所以，我无法弄清楚 ssl 隧道来自哪里（请参见屏幕截图）。我的想法是。
The devs missed something and one of the calls is http.
A network appliance is attempting to convert the call to https, though there are no url rewrites on the IIS server.
What would cause a black "xxx took too long to respond" to render while the default page is loading? It feels like a scenario where the request was changed before it was fully read or something like that.
After a proper investigation, the incoming requests, although over http, had the Upgrade-Insecure-Requests: header set to 1. This in essence caused the following events to occur in accordiance with HSTS or HTTP Strict Transport Security.
Solution: Add a valid ssl certificate binding to the website.
令人困惑的是，为什么浏览器在渲染回退到 http 响应之前渲染库存“请求花费太长时间”错误页面。好吧，如果检查调用链，我们可以看到其中一个重定向，我猜测是对 https 的升级，导致 Time 值（未知）。将鼠标悬停在记录上会显示附带的消息 - “该请求无法在此处显示，因为发出该请求的页面已卸载”。也许浏览器会将其解释为客户端已断开连接或退出等待响应。（内部的某些东西升级并请求 ssl，然后浏览器确定证书是错误的并放弃请求）回退到库存图像错误屏幕，而第二个重定向正在进行到成功的 http。
尝试升级然后降级的另一个视图。