8000 [HttpFoundation] Add a StreamedFileResponse. by niklasf · Pull Request #4323 · symfony/symfony · GitHub
[go: up one dir, main page]

Skip to content

[HttpFoundation] Add a StreamedFileResponse. #4323

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

Closed
wants to merge 1 commit into from

Conversation

niklasf
Copy link
Contributor
@niklasf niklasf commented May 18, 2012

In the Drupal 8 branch where we are trying to leverage Symfonys HTTP Kernel we
currently have something like this:

function file_download(...) {
  // [...]
  return new StreamedResponse(function() use ($uri)) {
    if (... && fopen($uri, 'rb')) {
      while (!feof($fd)) {
        print fread($fd, 1024);
      }
      fclose($fd);
    }
  }, 200, $headers);
}

This is bad because:

  • There might be better methods of streaming out a file, like X-Sendfile if
    available.
  • Code like this is duplicated in different places.

Obvious solution to the latter point: Factor that out to something like a
StreamedFileResponse. Basically, then, the question is why such a class
shouldn't be in Symfony itself.

Heres a sketch of what such a class would have to do. For discussion and as
context for the following questions, without testcoverage or a changelog entry
(yet).

  • Generally: Have something like that in Symfony?
  • Detail: How to do error handling? Can I throw exceptions from the HttpKernel
    component?
  • How to best enable the different transfer methods? The switch-case stuff
    doesn't look good. How to leverage the dependency injection container or
    keep it compatible with that?

In the Drupal 8 branch where we are trying to leverage Symfonys HTTP Kernel we
currently have something like this:

```
function file_download(...) {
  // [...]
  return new StreamedResponse(function() use ($uri)) {
    if (... && fopen($uri, 'rb')) {
      while (!feof($fd)) {
        print fread($fd, 1024);
      }
      fclose($fd);
    }
  }, 200, $headers);
}
```

This is bad because:
 - There might be better methods of streaming out a file, like X-Sendfile if
   available.
 - Code like this is duplicated in different places.

Obvious solution to the latter point: Factor that out to something like a
StreamedFileResponse. Basically, then, the question is why such a class
shouldn't be in Symfony itself.

Heres a sketch of what such a class would have to do. For discussion and as
context for the following questions, without testcoverage or a changelog entry
(yet).

 - Generally: Have something like that in Symfony?
 - Detail: How to do error handling? Can I throw exceptions from the HttpKernel
   component?
 - How to best enable the different transfer methods? The switch-case stuff
   doesn't look good. How to leverage the dependency injection container or
   keep it compatible with that?
@travisbot
Copy link

This pull request passes (merged 5be540d into 1e15f21).

@stof
Copy link
Member
stof commented May 18, 2012

If you want to serve files through Symfony, you can look at https://github.com/igorw/IgorwFileServeBundle

@vicb
Copy link
Contributor
vicb commented May 18, 2012

also check #3602

@niklasf
Copy link
Contributor Author
niklasf commented May 18, 2012

Thank you!

@Crell: Looks like there have been some efforts to bring in a simple BinaryFileResponse with one transfer method, because even that isn't trivial but would be very useful. Probably that should be revived. Such a class in Symfony would be awesome.
IgorwFileServeBundle looks great, too. With a dependency injection container for all the different transfer methods and stuff.

@niklasf niklasf closed this May 18, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
0