-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rework raw file http header logic #20464
Conversation
901ea2d
to
197d743
Compare
Added the I think it's reasonable safe to do this. The worst that could happen is that a PDF could CPU resources like described in https://bugs.chromium.org/p/chromium/issues/detail?id=413851#c24, but I don't think a full compromise is possible because PDF scripts can normally not escape the PDF document environment, and if they can, it's a plugin bug. |
But GitHub does set sandbox for pdf files imho |
No, they don't, at least not any longer. If they would, pdf attachments would not work in Safari and possibly Chrome as well. The do a 302 redirect to the separate domain. the redirect response does have CSP without curl -sLi 'https://github.com/silverwind/symlink-test/files/9175640/test.pdf' | grep -i content-security |
a64c8e8
to
a2cfcdb
Compare
Oops, I destroyed the PR by pushing |
content-disposition: attachment
, let the browser decide whether it wants to download or display a file directlysandbox
attribute.This change will make a lot more file types open directly in browser now. Logic should generally be more readable than before with less
if
nesting and such.Replaces: #20460
Replaces: #20455