nathank
6월 10, 2026, 3:14오전
1
Currently, I’m finding that clicking on the PDF link when a PDF preview is active currently attempts to download the PDF (undesired) instead of opening it in a new tab.
This is with simple self-hosting (single container, no CDN, no S3, horizon theme).
This whole thing was addressed back here:
The reason why this is a problem is that a common user desire is to read an inline PDF in the entire window, as the iframe is quite restrictive. Download adds an unecessarily annoying step. And there is already a download button in the toolbar of the PDF viewer in the iframe (at least there is in Chrome).
2개의 좋아요
We were being inconsistent with the display type depending on whether you were using S3 or not. That should be fixed by
main ← fix-inline-safe-uploads-local-store
approved 05:17PM - 14 Jul 26 UTC
Inline-safe uploads (images, PDFs, audio and video) served from the local
file s… tore were sent with `Content-Disposition: attachment`, so clicking a
PDF link downloaded the file instead of opening it in the browser. This was
inconsistent with the S3 store, which already serves these files inline, and
it left simple self-hosted (single-container, no S3/CDN) sites unable to open
PDFs inline.
`UploadsController#send_file_local_upload` only set the disposition to
`attachment` for unsafe types, and to `inline` when `?inline=1` was passed,
leaving it unset otherwise. Rails' `send_file` defaults an unset disposition
to `attachment`, so inline-safe files fell through to a download.
Inline-safe files are now served with `Content-Disposition: inline` by
default, mirroring the S3 store, while unsafe types (HTML, SVG, XML, ...) and
explicit downloads (`?dl=1`) keep the `attachment` disposition. The redundant
`params[:inline]` branch is removed, since inline-safe files are now inline by
default.
The `Content-Security-Policy: sandbox;` header stays on **every** response as
defense-in-depth: if the `is_inline_safe?` allowlist is ever wrong, the
sandbox forces an opaque origin and disables script execution so a
misclassified file cannot run as a document in our origin. It does not
interfere with inline viewing — `sandbox` sandboxes scripts *inside* the
served file, not the browser's native rendering of it. Chrome's built-in PDF
viewer and Firefox's pdf.js both render sandboxed PDFs identically to
unsandboxed ones, and images/audio/video decode natively regardless.
A spec locks the allowlist invariant by asserting no inline-safe extension
maps to a script-capable content type, so re-adding something like SVG or XML
to the allowlist fails CI instead of becoming a stored XSS.
(cc @david )
The fact that clicking on a file opens automatically in another tab is more a product
3개의 좋아요