>用户单击“下载”按钮
>我们的JS从服务器获取下载URL(它是一个超时URL,因此必须以这种方式完成)
> iframe被重定向到下载URL,其中包含附件的内容处理,因此浏览器开始下载而不更改页面的位置.
这适用于所有用户和浏览器……除了一些IE用户.
我试图重现这个问题,这就是我想出的：
>如果快速点击“保存或打开”对话框,下载始终有效
>如果慢慢点击“保存或打开”对话框(如10-20秒),下载有时会起作用,有时则不然.我一直无法找到一种模式.
这是它卡住时的样子：
问题不在于S3上的链接超时 – 我上面的实验完全在时间窗口内.
什么可能导致这些零星的下载失败？
更新
服务器日志表明下载完全发送给用户.
这可能是计时问题或HTTP问题.
时间问题
是否有可能另一个进程打开文件,甚至可能锁定它？也许是过度热心的反病毒或实时备份软件？有可能是关闭和重命名操作(必须在服务器发送整个文件后进行)如下所示：
>将最后一个有效字节写入fizzbuzz.partial文件
>关闭文件
>重命名文件
如果进程抓取文件以进行2到3之间的独占读取,该怎么办？也许该应用程序对文件进行了一些更改,比如写入一个让IE混淆的备用NTFS流？
请记住,浏览器插件也会通知下载结束.另一种计时问题可能是由于插件monitors the download,看到它结束,做了一些操作.在某些情况下,该操作可能会失败或永远不会返回
尝试在没有任何防病毒运行的情况下重现问题(比仅仅将文件列入白名单更好的测试)并且不加载任何浏览器插件.
HTTP问题
服务器和客户端必须就结束连接的方式达成一致.你必须：
>在传输结束时关闭连接
>指定下载的长度
很难从远处调试这个,但如果可能的话,捕获下载的网络跟踪并寻找这些线索：
> Content-length标头不存在或者可能是N(浏览器将永远等待N个字节不会出现)？
>每个客户端是否具有相同的代理配置？
>非工作客户端是否降级为HTTP 1.0？ (有一个名为“始终通过代理使用http 1.0”的设置
从您的屏幕截图来看,浏览器似乎无法计算估计的到达时间,但它与下载之间没有相关性.