微软Edge PDF内嵌问题

Question

微软Edge PDF内嵌问题

ruby-on-railsinternet-explorermicrosoft-edge

3

我们的Rails Web应用程序使用wkhtmltopdf生成PDF，并将其发送给客户端。我们已经在测试过的每个Web浏览器中尝试了几种不同的响应渲染方式，除了Edge之外都能正常工作。

我们尝试以几种不同的方式呈现响应，以下是最初的方式:

kit = PDFKit.new(@html_content)
render text: kit.to_pdf, content_type: 'application/pdf'

这将打开PDF查看器，我们测试过的所有浏览器都可以正确显示PDF，除了Edge浏览器，它会显示：“某些内容阻止了此PDF的打开。”

在我们的应用程序日志中，有一个POST请求，这是表单提交，我可以看到我们的应用程序发送了pdf文件响应，然后有对表单提交URL的后续GET请求错误，因为它不希望该URL接收任何GET请求。我不知道这里发生了什么。

该请求的响应头如下：

Cache-Control: max-age=0, private, must-revalidate
Connection: Keep-Alive
Content-Length: 34865
Content-Type: application/pdf; charset=utf-8
Date: Thu, 18 Jun 2015 14:35:30 GMT
Etag: "4baf297d1866339e60e8e893300909a0"
Server: WEBrick/1.3.1 (Ruby/2.0.0/2013-06-27)
Set-Cookie: _APP_session=<long cookie>; path=/; HttpOnly
X-Request-Id: 617580a8-4d7d-43c4-8e49-aeaeafba7b79
X-Runtime: 21.868098
X-XSS-Protection: 1; mode=block
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-ua-compatible: chrome=1

我也尝试使用 send_data 来实现：

send_data kit.to_pdf, type: 'application/pdf', disposition: 'inline'

这导致以下响应头，但最终仍存在相同的问题：

Cache-Control: private
Connection: Keep-Alive
Content-Disposition: inline
Content-Length: 34866
Content-Transfer-Encoding: binary
Content-Type: application/pdf
Date: Thu, 18 Jun 2015 14:39:42 GMT
Etag: "11db49f1a26444a38fa2b51f3c3336ed"
Server: WEBrick/1.3.1 (Ruby/2.0.0/2013-06-27)
Set-Cookie: _APP_session=<long cookie>; path=/; HttpOnly
X-Request-Id: 501d9832-b07e-4764-8ecc-f1c1e9a6421e
X-Runtime: 7.054236
X-XSS-Protection: 1; mode=block
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-ua-compatible: chrome=1

如果我从上面删除Content-Disposition: inline头，则会弹出保存文件提示，下载文件工作正常。但我们需要在浏览器窗口中加载它。

我不认为这是这个问题的重复，因为它在IE 9、10和11中工作正常，只有在Edge中存在问题。

- Mike Campbell

可能是生成PDF，IE和HTTPS出现错误的重复问题 // IE在处理PDF时对缓存头可能会有些棘手。如果这些不是“正确的”，那么它会在_displaying_ PDF之前发出第二个请求（这将是您看到的GET请求）。首先尝试将Cache-Control设置为public，如果仅此不能解决问题，请查看该问题答案中的其他缓存头。 - CBroe

“Cache-Control: max-age=0, private, must-revalidate” 这个设置肯定会在 IE 中出问题 - “must-revalidate” 会导致浏览器发出第二个请求。 - CBroe

@CBroe请注意我的第二个响应头，它只有Cache-Control: private，这是非常重要的，因为数据非常敏感。另外，我不确定它是否可以被视为那个问题的重复，因为正如所述，这段代码在IE 9、10和11中都能正常工作。 - Mike Campbell

1

至少尝试使用 public… - CBroe

嗯，也许其他一些标头有问题。我猜先保存PDF文件，然后重定向到一个可以通过GET方法检索的地址不是一个选择吗？ - CBroe

显示剩余2条评论

2个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- davidw · Answer 1

我们在服务器上生成并内联分发PDF报告时，遇到了似乎与其他人相同的问题 - 查看器打开的新标签页似乎重新发出了内容请求，而不是从响应中显示内容。由于我们使用合成的一次性路径（主要是出于历史原因，以确保获取报告的新版本），因此新标签页的GET请求实际上找不到报告。

由于我们正在使用20.10240，我不确定它是否在10158中得到了修复。

与OP一样，这似乎仅适用于“Content-Disposition：inline”；如果我们改用“attachment”，则会在本地保存临时文件，并在查看器中打开该临时文件。

- Mike Campbell · Answer 2

这是一个错误，但微软已经在10158版本中修复了它！:)