10000 BinaryFileResponse attachment doesn't work with non-ascii filenames · Issue #16603 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content

BinaryFileResponse attachment doesn't work with non-ascii filenames #16603

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.

Sign up for GitHub

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

Jump to bottom
Closed
Yannik opened this issue Nov 19, 2015 · 5 comments
Closed

BinaryFileResponse attachment doesn't work with non-ascii filenames #16603

Yannik opened this issue Nov 19, 2015 · 5 comments
Labels
Bug HttpFoundation Status: Reviewed

Comments

@Yannik
Copy link
Yannik commented Nov 19, 2015

Hi everyone,

at the moment, it is impossible to create a BinaryFileResponse with a file which has a non-ascii filename:

<?php
function test_can_create_utf8_file_attachment_response() {
    touch('Täst');
    new Symfony\Component\HttpFoundation\BinaryFileResponse('Täst', 200, [], true, 'attachment');
}

This results in a InvalidArgumentException with message 'The filename fallback must only contain ASCII characters.'

The stacktrace for the exception is:

#0 symfony\http-foundation\BinaryFileResponse.php(161): Symfony\Component\HttpFoundation\ResponseHeaderBag->makeDisposition('attachment', 'T\xC3\xA4st', '')
#1 symfony\http-foundation\BinaryFileResponse.php(110): Symfony\Component\HttpFoundation\BinaryFileResponse->setContentDisposition('attachment')
#2 symfony\http-foundation\BinaryFileResponse.php(50): Symfony\Component\HttpFoundation\BinaryFileResponse->setFile('T\xC3\xA4st', 'attachment', false, true)
#3 test.php(3) : Symfony\Component\HttpFoundation\BinaryFileResponse->__construct('T\xC3\xA4st', 200, Array, true, 'attachment')

However, it is not possible to instantiate a BinaryFileResponse and pass a filename fallback.
In fact, when setContentDisposition is called without a fallback filename (as is done by setFile), according to the DocBlock:

     * @param string $filenameFallback A fallback filename, containing only ASCII characters. Defaults to an automatically encoded filename

the fallback filename should default to a automatically created ascii version.
However, this does not happen:

    public function  setContentDisposition($disposition, $filename = '', $filenameFallback = '')
    {
        if ($filename === '') {
            $filename = $this->file->getFilename();
        }

        $dispositionHeader = $this->headers->makeDisposition($disposition, $filename, $filenameFallback);
    }

$filenameFallback is just left to be a empty string.
makeDisposition then sets the fallback filename to the (possibly utf8) filename gotten though getFilename():

        if ('' == $filenameFallback) {
            $filenameFallback = $filename;
        }

which then causes the exception.

Possible solutions:

  1. Let setContentDisposition act as it's docblock describes and set the fallback filename to an automatically encoded version of the filename if no other fallback filename is given
  2. Pass filename and fallback filename in the constructur and change the docblock of setContentDisposition
  3. both
@xabbuh xabbuh mentioned this issue Nov 24, 2015
Merged
@xabbuh xabbuh added the Bug label Nov 24, 2015
@xabbuh
Copy link
Member
xabbuh commented Nov 24, 2015

see #16656

@xabbuh
Copy link
Member
xabbuh commented Nov 24, 2015

Status: Reviewed

@Yannik
Copy link
Author
Yannik commented Nov 25, 2015

Thanks a lot for addressing this, @xabbuh! I commented on your pull request about maybe replacing the non-ascii chars with their nearest ascii equivalent instead of just replacing them with an underscore. I would be very grateful if you could consider this. Thanks, Yannik

@nicolas-grekas
Copy link
Member

This is RFC 2231
See also this old "paper" on the topic: http://greenbytes.de/tech/tc2231/
Doing transliterations works for western languages but is quite limited in the general case...

@ghost
Copy link
ghost commented Jan 31, 2016

+1 👍 Had the issue today.

fabpot added a commit that referenced this issue Mar 4, 2016
@fabpot
bug #16656 [HttpFoundation] automatically generate safe fallback file…
5bbe951 
…name (xabbuh)

This PR was merged into the 2.3 branch.

Discussion
----------

[HttpFoundation] automatically generate safe fallback filename

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #16603
| License       | MIT
| Doc PR        |

Commits
-------

03721e3 automatically generate safe fallback filename
@fabpot fabpot closed this as completed Mar 4, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug HttpFoundation Status: Reviewed
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@fabpot @nicolas-grekas @Yannik @xabbuh @carsonbot
0