在浏览器中显示PDF时，大多数（IE，FF，Safari，Chrome，Opera）是否为PDF文件生成多个HTTP请求？我正在研究与WebTrends Web Analytics软件集成的问题，围绕PDF的统计数据似乎不正确。支持告诉我，因为WebTrends解析Web服务器访问日志以确定流量，下载等，所以很难确定准确的PDF下载，因为：
当用户点击PDF并通过Acrobat Reader浏览器插件在用户浏览器中打开PDF时，每个页面一次一个地下载 - 如果用户仅查看该页面，则会这样做以节省带宽50页PDF的前2页，只下载前2页。
这对我来说听起来很可疑（如何将HTTP请求仅用于提供二进制文件的一部分？） - 我一直在搜索谷歌，但没有发现任何与此有关的内容。
我将尝试找一些IE软件，让我明天嗅探HTTP流量，看看我是否能观察到这种现象。
任何信息/想法都很受欢迎。
如果您的站点返回如下的HTTP响应标头：
Accept-Ranges: bytes
阅读文档的几KB后，PDF阅读器将关闭初始连接。然后，它根据需要使用Range请求标头请求文档的各个部分，例如：
Range: bytes=242107-244329, 8060-76128
执行此操作的URL的示例是 http://www.ovationguitars.com/img/OVmanual.pdf 。
如果您不返回Accept-Ranges标题，则PDF文档将在单个请求中下载（例如， http://manuals.info.apple.com/en/iphone_user_guide.pdf ）
您可以使用IE查看PDF阅读器的行为 HttpWatch的。
**免责声明：此答案由HttpWatch的制造商Simtec Limited发布**
对于我来说，截至2016年6月，Firefox和IE11只拨打一个电话。
如果没有，Chrome会拨打两个电话 Content-Disposition 头。如果缺少，Chrome会执行两次GET，似乎取消第二次，并在浏览器中显示PDF。服务器不知道第二个被取消，并再次发送PDF。
从服务器发送此标头时，Chrome只会拨打一个电话并启动或保存该文件。
Content-Disposition: attachment
（您还可以建议用户保存文件时使用的文件名...）
Content-Disposition: attachment; filename=test.pdf
我的想法是你的位置：你的插件不能（也不应该）将PDF分成请求。
我有一个Web应用程序，它根据请求（单个请求）提供PDF文件并显示在插件中。它显示整个PDF而不会获得任何更多信息。
此外，如果您正在寻找HTTP嗅探器，您可以尝试 提琴手。我发现在网站调试期间这很有用。
在我的测试中，如果我启用了REST控制台4.0.2扩展，则对Chrome的双重请求会在Chrome中出现。停用此扩展程序可使Chrome按预期工作（只有一个请求）。
编辑：启用Instapaper扩展程序也会使Chrome对PDF进行双重请求。