Http Response 标头的执行顺序？答案

【问题标题】：Execution order of Http Response headers?Http Response 标头的执行顺序？
【发布时间】：2014-02-05 03:57:41
【问题描述】：

我看到 this plugin 使用 Ajax 和一些其他后备技术下载文件。

但是由于不是所有浏览器都支持ajax下载文件功能，所以他在iframe上使用了一个技巧。（这很容易实现）

但有一件事引起了我的注意：

他还添加了一个选项，告诉您文件何时完成下载。

他是通过cookie 做到的。他通过setInterval 进行投票以查看cookie。只要cookie 不存在 - 文件未完成下载。（当cookie 存在时 - 文件已下载）

所以下载文件的头部是：

Content-Disposition: attachment; filename=Report0.pdf

他补充说：

Set-Cookie: fileDownload=true; path=/

但后来我想 - 谁说 set-cookie 在文件下载完成后被称为？

问题：

查看实际的标题：

1 - 浏览器是否消化每个标题按实际出现的顺序？

2 - 是否有任何标题必须出现在其他标题之前？

3 - 每个标题的摘要是否会阻塞摘要，直到当前的摘要完成？我的意思是：content-disposition:attachment;filename=1.jpg 行是否会阻止浏览器消化下一个标头 - 直到 filename=1.jpg 完成加载？

我也尝试通过 fiddler 进行调查，但没有得到任何结论。（我的意思是如何在 fiddler 中测试它？）

【问题讨论】：

【解决方案1】：

你的怀疑是对的。

没有要求客户端等到响应正文完成后才评估正文之前的 Set-Cookie 标头，事实上有充分的理由相信大多数浏览器会在正文完成之前设置 cookie（因为许多网页会在 HTML 页面内的 JavaScript 中查看 document.cookie）。

事实上，我对此进行了测试（使用 MeddlerScript 你可以在这里看到：http://pastebin.com/SUwCFyxS），发现 IE、Chrome 和 Firefox 都在下载完成之前设置了 cookie，并且即使用户点击“取消”也设置了 cookie " 在下载中。

HTTP 规范包含 Trailer 的概念（它是出现在响应正文之后的标头），但这些概念很少使用，并且在许多客户端（例如 WinINET/IE）中不受支持。如果客户端确实支持Trailers，服务器可以在主体之后发送Set-Cookie标头，这意味着客户端在主体完成下载之前看不到它。

【讨论】：

但是埃里克，当响应是附件时，这些规则是否可能不适用？（content-disposition:attachment）？我的意思是 - 你如何解释 cookie 是在文件 100% 下载之后设置的？（我确实测试过...）
正如我所说，没有要求客户端等到响应正文完成才能评估Set-Cookie 标头。您能否提供一个表明浏览器正在等待的重现 URL？
因此，基于 cookie 来判断文件是否已下载的插件代码 - 有一个基本的缺陷假设。（我问因为我要在我的网站上实现它）。（感谢 Eric）
是的，cookie是在下载开始时设置的。我建立了一个测试来证明它并更新了我的答案。如果您阅读原始文章，那正是他们想要做的——检测下载的开始，而不是结束。话虽如此，即使检测到开始也有点粗略，因为您永远不知道用户是否在中间单击了 Cancel。
无法要求更多，埃里克。谢谢