从浏览器中显示 PDF 时，大多数浏览器是否会发出多个 HTTP 请求答案

【问题标题】：Do most browsers make multiple HTTP Requests when displaying a PDF from within the browser从浏览器中显示 PDF 时，大多数浏览器是否会发出多个 HTTP 请求
【发布时间】：2010-12-21 12:35:33
【问题描述】：

在浏览器中显示 PDF 时，大多数（IE、FF、Safari、Chrome、Opera）是否会对 PDF 文件发出多个 HTTP 请求？我正在处理一个与 WebTrends Web Analytics 软件集成的问题，而关于 PDF 的统计数据似乎不正确。支持人员告诉我，由于 WebTrends 会解析 Web 服务器访问日志以确定流量、下载量等，因此很难确定准确的 PDF 下载，因为：
当用户单击 PDF 并通过 Acrobat Reader 浏览器插件在用户的浏览器中打开 PDF 时，每次下载一个页面 - 如果用户只查看50 页 PDF 的前 2 页，仅下载前 2 页。

这对我来说听起来很可疑（如何发出 HTTP 请求来只提供二进制文件的一部分？）——我一直在搜索 Google，但没有找到任何与此相关的内容。

我明天会尝试找一些IE软件让我嗅探HTTP流量，看看我是否能观察到这种现象。

感谢任何信息/想法。

【问题讨论】：

不是这样的答案，但 http 确实支持通过 content-range 标头下载部分文件。也许 PDF 使用它... 耸耸肩
我发现 Fiddler 对于这种 IP 数据包嗅探非常方便。
见RFC 2616, Section 3.12。

标签： http pdf

【解决方案1】：

在我的测试中，如果我启用了 REST 控制台 4.0.2 扩展程序，Chrome 中会出现对 PDF 的双重请求。禁用此扩展程序可使 Chrome 按预期工作（只有一个请求）。

编辑：启用 Instapaper 扩展也会使 Chrome 对 PDF 进行双重请求。

【讨论】：

【解决方案2】：

对我而言，截至 2016 年 6 月，Firefox 和 IE11 只打一个电话。

如果没有 Content-Disposition 标头，Chrome 会进行两次调用。当它丢失时，Chrome 会执行两次 GET，似乎取消了第二次，并在浏览器中显示 PDF。服务器不知道第二个被取消了，再次发出PDF。

从服务器发送此标头时，Chrome 只进行一次调用并启动或保存文件。

Content-Disposition: attachment

（也可以建议用户保存文件时使用的文件名...）

Content-Disposition: attachment; filename=test.pdf

【讨论】：

添加此标头确实会阻止第二次调用，但也会导致 Chrome 像附件一样下载 PDF，而不是立即在浏览器中打开它。
是的。我仍然认为这是一个错误，但这是解决它的一种方法。
问题出在 Chrome 的 PDF 插件上。使用 Content-Disposition: 附件时，不使用 PDF 插件。这就是没有错误的原因。更多细节在这里：bugs.chromium.org/p/chromium/issues/detail?id=587709

【解决方案3】：

如果您的网站返回这样的 HTTP 响应标头：

Accept-Ranges: bytes

PDF 阅读器将在阅读几 KB 文档后关闭初始连接。然后它会根据需要使用 Range 请求标头请求文档的各个部分，例如：

Range: bytes=242107-244329, 8060-76128

http://www.ovationguitars.com/img/OVmanual.pdf 是一个 URL 示例。

如果您不返回 Accept-Ranges 标头，则 PDF 文档将在单个请求中下载（例如 http://manuals.info.apple.com/en/iphone_user_guide.pdf）

您可以使用HttpWatch 在 IE 中查看 PDF 阅读器的行为。

** 免责声明：此答案由 HttpWatch 的制造商 Simtec Limited 发布 **

【讨论】：

非常有趣，谢谢！所以看起来这是可能的，但是在进一步调查（观看 HTTPRequests/Respsonses）之后，用于 IE 的 Adobe Acrobat 阅读器插件似乎不支持以这种方式创建请求（并且可能也不支持为 PDF 提供服务的 Web 应用程序，尽管我还没有向它发送任何字节范围的合成请求）
我在 Chrome 中检查了 iphone_user_guide.pdf (manuals.info.apple.com/MANUALS/1000/MA1565/en_US/…) 并收到 2 个请求：第一个没问题。第二个被取消了。
我今天仍然看到这种行为，Fiddler 显示没有涉及“接受范围”标头。
仅供参考 - 我尝试禁用 Chrome 的 PDF 查看器并使用 PDF.js plugin for Chrome（FF 使用的） - Chrome 仍然继续发出（然后取消）第二个请求......

【解决方案4】：

我的想法是，你是正确的：你的插件不能（也不应该）将 PDF 拆分为请求。

我有一个 Web 应用程序，它通过请求（单个请求）提供 PDF 文件并显示在插件中。它显示整个 PDF 而不获取更多信息。

另外，如果您正在寻找 HTTP 嗅探器，您可以尝试Fiddler。我发现这在网站调试过程中很有用。

【讨论】：

我在 HTTPWatch 中使用 IE（该公司的官方“支持”浏览器）和最新的 Adobe Acrobat 阅读器插件检查了它，它正在拉下整个 PDF。我在标题中没有看到任何关于字节范围的内容。