Skip to content
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

send_file: allow filename for inline content-disposition #1869

Closed
ThiefMaster opened this issue Jun 29, 2020 · 2 comments · Fixed by #1884
Closed

send_file: allow filename for inline content-disposition #1869

ThiefMaster opened this issue Jun 29, 2020 · 2 comments · Fixed by #1884
Assignees
Milestone

Comments

@ThiefMaster
Copy link
Member

send_file should support attachment_filename even for content-disposition inline.

Including a filename with inline files makes perfect sense e.g. when serving images users may want to "rightclick -> save as".
To avoid breaking API changes I would recommend keeping attachment_filename for it, but sending a content-disposition:inline header in case as_attachment is false. Alternatively we could deprecate attachment_filename in favor of a new client_filename, where the old kwarg would not add an inline disposition while the new one would.

This depends on #1850 since it moves send_file from Flask to werkzeug.

@davidism davidism added this to the 2.0.0 milestone Jul 12, 2020
@davidism
Copy link
Member

davidism commented Jul 12, 2020

Since this is essentially a fresh start, we can just rename it client_filename with the behavior described. Flask's send_file will still exist as it has to get various Flask-specific data, so it can do the deprecation there.

If client_filename is set, set disposition to inline, unless as_attachment is set too, then set disposition to attachment.

@davidism
Copy link
Member

download_name seems like a clearer description of what the parameter does.

@davidism davidism self-assigned this Jul 13, 2020
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 13, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants