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

[HttpFoundation] added support for streamed responses #2935

Merged
merged 5 commits into from Dec 31, 2011

Conversation

Projects
None yet
@fabpot
Member

fabpot commented Dec 21, 2011

To stream a Response, use the StreamedResponse class instead of the
standard Response class:

$response = new StreamedResponse(function () {
    echo 'FOO';
});

$response = new StreamedResponse(function () {
    echo 'FOO';
}, 200, array('Content-Type' => 'text/plain'));

As you can see, a StreamedResponse instance takes a PHP callback instead of
a string for the Response content. It's up to the developer to stream the
response content from the callback with standard PHP functions like echo.
You can also use flush() if needed.

From a controller, do something like this:

$twig = $this->get('templating');

return new StreamedResponse(function () use ($templating) {
    $templating->stream('BlogBundle:Annot:streamed.html.twig');
}, 200, array('Content-Type' => 'text/html'));

If you are using the base controller, you can use the stream() method instead:

return $this->stream('BlogBundle:Annot:streamed.html.twig');

You can stream an existing file by using the PHP built-in readfile() function:

new StreamedResponse(function () use ($file) {
    readfile($file);
}, 200, array('Content-Type' => 'image/png');

Read http://php.net/flush for more information about output buffering in PHP.

Note that you should do your best to move all expensive operations to
be "activated/evaluated/called" during template evaluation.

Templates

If you are using Twig as a template engine, everything should work as
usual, even if are using template inheritance!

However, note that streaming is not supported for PHP templates. Support
is impossible by design (as the layout is rendered after the main content).

Exceptions

Exceptions thrown during rendering will be rendered as usual except that
some content might have been rendered already.

Limitations

As the getContent() method always returns false for streamed Responses, some
event listeners won't work at all:

  • Web debug toolbar is not available for such Responses (but the profiler works fine);
  • ESI is not supported.

Also note that streamed responses cannot benefit from HTTP caching for obvious
reasons.

[HttpFoundation] added support for streamed responses
To stream a Response, use the StreamedResponse class instead of the
standard Response class:

    $response = new StreamedResponse(function () {
        echo 'FOO';
    });

    $response = new StreamedResponse(function () {
        echo 'FOO';
    }, 200, array('Content-Type' => 'text/plain'));

As you can see, a StreamedResponse instance takes a PHP callback instead of
a string for the Response content. It's up to the developer to stream the
response content from the callback with standard PHP functions like echo.
You can also use flush() if needed.

From a controller, do something like this:

    $twig = $this->get('templating');

    return new StreamedResponse(function () use ($templating) {
        $templating->stream('BlogBundle:Annot:streamed.html.twig');
    }, 200, array('Content-Type' => 'text/html'));

If you are using the base controller, you can use the stream() method instead:

    return $this->stream('BlogBundle:Annot:streamed.html.twig');

You can stream an existing file by using the PHP built-in readfile() function:

    new StreamedResponse(function () use ($file) {
        readfile($file);
    }, 200, array('Content-Type' => 'image/png');

Read http://php.net/flush for more information about output buffering in PHP.

Note that you should do your best to move all expensive operations to
be "activated/evaluated/called" during template evaluation.

Templates
---------

If you are using Twig as a template engine, everything should work as
usual, even if are using template inheritance!

However, note that streaming is not supported for PHP templates. Support
is impossible by design (as the layout is rendered after the main content).

Exceptions
----------

Exceptions thrown during rendering will be rendered as usual except that
some content might have been rendered already.

Limitations
-----------

As the getContent() method always returns false for streamed Responses, some
event listeners won't work at all:

* Web debug toolbar is not available for such Responses (but the profiler works fine);
* ESI is not supported.

Also note that streamed responses cannot benefit from HTTP caching for obvious
reasons.
*/
public function prepare(Request $request)
{
if ('1.0' != $request->server->get('SERVER_PROTOCOL')) {

This comment has been minimized.

@jalliot

jalliot Dec 21, 2011

Contributor

Should be !== for CS no?

@jalliot

jalliot Dec 21, 2011

Contributor

Should be !== for CS no?

static public function getSubscribedEvents()
{
return array(
KernelEvents::RESPONSE => array('onKernelResponse', -1024),

This comment has been minimized.

@stof

stof Dec 21, 2011

Member

why do we need this listener at the end of the kernel.response event ? The event is the last step before the end of the request and send will be called by the front controller just after that.

@stof

stof Dec 21, 2011

Member

why do we need this listener at the end of the kernel.response event ? The event is the last step before the end of the request and send will be called by the front controller just after that.

This comment has been minimized.

@fabpot

fabpot Dec 21, 2011

Member

It must be the last one as we are sending the content here. The send() in the front controller is a no-op for streamed responses.

@fabpot

fabpot Dec 21, 2011

Member

It must be the last one as we are sending the content here. The send() in the front controller is a no-op for streamed responses.

This comment has been minimized.

@Seldaek

Seldaek Dec 21, 2011

Member

Why do you have this event listener at all actually? Can't you just let the send() method be called as usual by the front controller? Sounds like it's equivalent to me.

@Seldaek

Seldaek Dec 21, 2011

Member

Why do you have this event listener at all actually? Can't you just let the send() method be called as usual by the front controller? Sounds like it's equivalent to me.

This comment has been minimized.

@fabpot

fabpot Dec 22, 2011

Member

The event listener is needed because we need to be in the request scope to be able to generate the response. If you send the response in the front controller, the request is not available anymore.

@fabpot

fabpot Dec 22, 2011

Member

The event listener is needed because we need to be in the request scope to be able to generate the response. If you send the response in the front controller, the request is not available anymore.

use Symfony\Component\EventDispatcher\EventSubscriberInterface;
/**
* StreamedResponseListener is responsible for sending the Response

This comment has been minimized.

@Tobion

Tobion Dec 21, 2011

Member

type: response

@Tobion

Tobion Dec 21, 2011

Member

type: response

This comment has been minimized.

@lsmith77

lsmith77 Dec 22, 2011

Contributor

i think we do this in other places too when we want to refer to a class instance.

@lsmith77

lsmith77 Dec 22, 2011

Contributor

i think we do this in other places too when we want to refer to a class instance.

@Seldaek

This comment has been minimized.

Show comment
Hide comment
@Seldaek

Seldaek Dec 21, 2011

Member

Just an idea: what about exposing flush() to twig? Possibly in a way that it will not call it if the template is not streaming. That way you could always add a flush() after your tag to make sure that goes out as fast as possible, but it wouldn't mess with non-streamed responses. Although it appears flush() doesn't affect output buffers, so I guess it doesn't need anything special.

When you say "ESI is not supported.", that means only the AppCache right? I don't see why this would affect Varnish, but then again as far as I know Varnish will buffer if ESI is used so the benefit of streaming there is non-existent.

Member

Seldaek commented Dec 21, 2011

Just an idea: what about exposing flush() to twig? Possibly in a way that it will not call it if the template is not streaming. That way you could always add a flush() after your tag to make sure that goes out as fast as possible, but it wouldn't mess with non-streamed responses. Although it appears flush() doesn't affect output buffers, so I guess it doesn't need anything special.

When you say "ESI is not supported.", that means only the AppCache right? I don't see why this would affect Varnish, but then again as far as I know Varnish will buffer if ESI is used so the benefit of streaming there is non-existent.

@cordoval

This comment has been minimized.

Show comment
Hide comment
@cordoval

cordoval Dec 21, 2011

Contributor

wonder what the use case is for streaming a response, very interesting.

Contributor

cordoval commented Dec 21, 2011

wonder what the use case is for streaming a response, very interesting.

@johnkary

This comment has been minimized.

Show comment
Hide comment
@johnkary

johnkary Dec 21, 2011

Contributor

@cordoval Common use cases are present fairly well by this RailsCast video: http://railscasts.com/episodes/266-http-streaming

Essentially it allows faster fetching of web assets (JS, CSS, etc) located in the <head></head>, allowing those assets to be fetched as soon as possible before the remainder of the content body is computed and sent to the browser. The end goal is to improve page load speed.

There are other uses cases too like making large body content available quickly to the service consuming it. Think if you were monitoring a live feed of JSON data of newest Twitter comments.

Contributor

johnkary commented Dec 21, 2011

@cordoval Common use cases are present fairly well by this RailsCast video: http://railscasts.com/episodes/266-http-streaming

Essentially it allows faster fetching of web assets (JS, CSS, etc) located in the <head></head>, allowing those assets to be fetched as soon as possible before the remainder of the content body is computed and sent to the browser. The end goal is to improve page load speed.

There are other uses cases too like making large body content available quickly to the service consuming it. Think if you were monitoring a live feed of JSON data of newest Twitter comments.

@lsmith77

This comment has been minimized.

Show comment
Hide comment
@lsmith77

lsmith77 Dec 21, 2011

Contributor

How does this relate the limitations mentioned in:
http://yehudakatz.com/2010/09/07/automatic-flushing-the-rails-3-1-plan/

Am I right to understand that due to how twig works we are not really streaming the content pieces when we call render(), but instead the entire template with its layout is rendered and only then will we flush? or does it mean that the render call will work its way to the top level layout template and form then on it can send the content until it hits another block, which it then first renders before it continues to send the data?

Contributor

lsmith77 commented Dec 21, 2011

How does this relate the limitations mentioned in:
http://yehudakatz.com/2010/09/07/automatic-flushing-the-rails-3-1-plan/

Am I right to understand that due to how twig works we are not really streaming the content pieces when we call render(), but instead the entire template with its layout is rendered and only then will we flush? or does it mean that the render call will work its way to the top level layout template and form then on it can send the content until it hits another block, which it then first renders before it continues to send the data?

@stof

This comment has been minimized.

Show comment
Hide comment
@stof

stof Dec 21, 2011

Member

@lsmith77 this is why the stream method calls display in Twig instead of render. display uses echo to print the output of the template line by line (and blocks are simply method calls in the middle). Look at your compiled templates to see it (the doDisplay method)
Rendering a template with Twig simply use an output buffer around the rendering.

Member

stof commented Dec 21, 2011

@lsmith77 this is why the stream method calls display in Twig instead of render. display uses echo to print the output of the template line by line (and blocks are simply method calls in the middle). Look at your compiled templates to see it (the doDisplay method)
Rendering a template with Twig simply use an output buffer around the rendering.

@fabpot

This comment has been minimized.

Show comment
Hide comment
@fabpot

fabpot Dec 21, 2011

Member

@lsmith77: We don't have the Rails problem thanks to Twig as the order of execution is the right one by default (the layout is executed first); it means that we can have the flush feature without any change to how the core works. As @stof mentioned, we are using display, not render, so we are streaming your templates for byte one.

Member

fabpot commented Dec 21, 2011

@lsmith77: We don't have the Rails problem thanks to Twig as the order of execution is the right one by default (the layout is executed first); it means that we can have the flush feature without any change to how the core works. As @stof mentioned, we are using display, not render, so we are streaming your templates for byte one.

@fabpot

This comment has been minimized.

Show comment
Hide comment
@fabpot

fabpot Dec 21, 2011

Member

@Seldaek: yes, I meant ESI with the PHP reverse proxy.

Member

fabpot commented Dec 21, 2011

@Seldaek: yes, I meant ESI with the PHP reverse proxy.

@fabpot

This comment has been minimized.

Show comment
Hide comment
@fabpot

fabpot Dec 21, 2011

Member

@Seldaek: I have flush() support for Twig on my todo-list. As you mentioned, It should be trivial to implement.

Member

fabpot commented Dec 21, 2011

@Seldaek: I have flush() support for Twig on my todo-list. As you mentioned, It should be trivial to implement.

@fzaninotto

This comment has been minimized.

Show comment
Hide comment
@fzaninotto

fzaninotto Dec 21, 2011

Contributor

How do streaming responses deal with assets that must be called in the head, but are declared in the body?

Contributor

fzaninotto commented Dec 21, 2011

How do streaming responses deal with assets that must be called in the head, but are declared in the body?

@fabpot

This comment has been minimized.

Show comment
Hide comment
@fabpot

fabpot Dec 21, 2011

Member

@fzaninotto: What do you mean?

With Twig, your layout is defined with blocks ("holes"). These blocks are overridden by child templates, but evaluated as they are encountered in the layout. So, everything works as expected.

As noted in the commit message, this does not work with PHP templates for the problems mentioned in the Rails post (as the order of execution is not the right one -- the child template is first evaluated and then the layout).

Member

fabpot commented Dec 21, 2011

@fzaninotto: What do you mean?

With Twig, your layout is defined with blocks ("holes"). These blocks are overridden by child templates, but evaluated as they are encountered in the layout. So, everything works as expected.

As noted in the commit message, this does not work with PHP templates for the problems mentioned in the Rails post (as the order of execution is not the right one -- the child template is first evaluated and then the layout).

@fzaninotto

This comment has been minimized.

Show comment
Hide comment
@fzaninotto

fzaninotto Dec 21, 2011

Contributor

I was referring to using Assetic. Not sure if this compiles to Twig the same way as javascript and stylesheet blocks placed in the head - and therefore executed in the right way.

Contributor

fzaninotto commented Dec 21, 2011

I was referring to using Assetic. Not sure if this compiles to Twig the same way as javascript and stylesheet blocks placed in the head - and therefore executed in the right way.

@fabpot

This comment has been minimized.

Show comment
Hide comment
@fabpot

fabpot Dec 21, 2011

Member

@Seldaek: I've just added a flush tag in Twig 1.5: fabpot/Twig@1d6dfad

Member

fabpot commented Dec 21, 2011

@Seldaek: I've just added a flush tag in Twig 1.5: fabpot/Twig@1d6dfad

@catchamonkey

This comment has been minimized.

Show comment
Hide comment
@catchamonkey

catchamonkey Dec 21, 2011

Contributor

I'm really happy you've got this into the core, it's a great feature to have! Good work.

Contributor

catchamonkey commented Dec 21, 2011

I'm really happy you've got this into the core, it's a great feature to have! Good work.

$this->headers->set('Transfer-Encoding', 'chunked');
}
$this->headers->set('Cache-Control', 'no-cache');

This comment has been minimized.

@vicb

vicb Dec 21, 2011

Contributor

There is probably a good reason to avoid caching but I can not figure out, any hint ?

semantic: maybe this should be moved after the call to the parent method ?

@vicb

vicb Dec 21, 2011

Contributor

There is probably a good reason to avoid caching but I can not figure out, any hint ?

semantic: maybe this should be moved after the call to the parent method ?

fabpot added a commit that referenced this pull request Dec 31, 2011

merged branch symfony/streaming (PR #2935)
Commits
-------

887c0e9 moved EngineInterface::stream() to a new StreamingEngineInterface to keep BC with 2.0
473741b added the possibility to change a StreamedResponse callback after its creation
8717d44 moved a test in the constructor
e44b8ba made some cosmetic changes
0038d1b [HttpFoundation] added support for streamed responses

Discussion
----------

[HttpFoundation] added support for streamed responses

To stream a Response, use the StreamedResponse class instead of the
standard Response class:

    $response = new StreamedResponse(function () {
        echo 'FOO';
    });

    $response = new StreamedResponse(function () {
        echo 'FOO';
    }, 200, array('Content-Type' => 'text/plain'));

As you can see, a StreamedResponse instance takes a PHP callback instead of
a string for the Response content. It's up to the developer to stream the
response content from the callback with standard PHP functions like echo.
You can also use flush() if needed.

From a controller, do something like this:

    $twig = $this->get('templating');

    return new StreamedResponse(function () use ($templating) {
        $templating->stream('BlogBundle:Annot:streamed.html.twig');
    }, 200, array('Content-Type' => 'text/html'));

If you are using the base controller, you can use the stream() method instead:

    return $this->stream('BlogBundle:Annot:streamed.html.twig');

You can stream an existing file by using the PHP built-in readfile() function:

    new StreamedResponse(function () use ($file) {
        readfile($file);
    }, 200, array('Content-Type' => 'image/png');

Read http://php.net/flush for more information about output buffering in PHP.

Note that you should do your best to move all expensive operations to
be "activated/evaluated/called" during template evaluation.

Templates
---------

If you are using Twig as a template engine, everything should work as
usual, even if are using template inheritance!

However, note that streaming is not supported for PHP templates. Support
is impossible by design (as the layout is rendered after the main content).

Exceptions
----------

Exceptions thrown during rendering will be rendered as usual except that
some content might have been rendered already.

Limitations
-----------

As the getContent() method always returns false for streamed Responses, some
event listeners won't work at all:

* Web debug toolbar is not available for such Responses (but the profiler works fine);
* ESI is not supported.

Also note that streamed responses cannot benefit from HTTP caching for obvious
reasons.

---------------------------------------------------------------------------

by Seldaek at 2011/12/21 06:34:13 -0800

Just an idea: what about exposing flush() to twig? Possibly in a way that it will not call it if the template is not streaming. That way you could always add a flush() after your </head> tag to make sure that goes out as fast as possible, but it wouldn't mess with non-streamed responses. Although it appears flush() doesn't affect output buffers, so I guess it doesn't need anything special.

When you say "ESI is not supported.", that means only the AppCache right? I don't see why this would affect Varnish, but then again as far as I know Varnish will buffer if ESI is used so the benefit of streaming there is non-existent.

---------------------------------------------------------------------------

by cordoval at 2011/12/21 08:04:21 -0800

wonder what the use case is for streaming a response, very interesting.

---------------------------------------------------------------------------

by johnkary at 2011/12/21 08:19:48 -0800

@cordoval Common use cases are present fairly well by this RailsCast video: http://railscasts.com/episodes/266-http-streaming

Essentially it allows faster fetching of web assets (JS, CSS, etc) located in the &lt;head>&lt;/head>, allowing those assets to be fetched as soon as possible before the remainder of the content body is computed and sent to the browser. The end goal is to improve page load speed.

There are other uses cases too like making large body content available quickly to the service consuming it. Think if you were monitoring a live feed of JSON data of newest Twitter comments.

---------------------------------------------------------------------------

by lsmith77 at 2011/12/21 08:54:35 -0800

How does this relate the limitations mentioned in:
http://yehudakatz.com/2010/09/07/automatic-flushing-the-rails-3-1-plan/

Am I right to understand that due to how twig works we are not really streaming the content pieces when we call render(), but instead the entire template with its layout is rendered and only then will we flush? or does it mean that the render call will work its way to the top level layout template and form then on it can send the content until it hits another block, which it then first renders before it continues to send the data?

---------------------------------------------------------------------------

by stof at 2011/12/21 09:02:53 -0800

@lsmith77 this is why the ``stream`` method calls ``display`` in Twig instead of ``render``. ``display`` uses echo to print the output of the template line by line (and blocks are simply method calls in the middle). Look at your compiled templates to see it (the ``doDisplay`` method)
Rendering a template with Twig simply use an output buffer around the rendering.

---------------------------------------------------------------------------

by fabpot at 2011/12/21 09:24:33 -0800

@lsmith77: We don't have the Rails problem thanks to Twig as the order of execution is the right one by default (the layout is executed first); it means that we can have the flush feature without any change to how the core works. As @stof mentioned, we are using `display`, not `render`, so we are streaming your templates for byte one.

---------------------------------------------------------------------------

by fabpot at 2011/12/21 09:36:41 -0800

@Seldaek: yes, I meant ESI with the PHP reverse proxy.

---------------------------------------------------------------------------

by fabpot at 2011/12/21 09:37:34 -0800

@Seldaek: I have `flush()` support for Twig on my todo-list. As you mentioned, It should be trivial to implement.

---------------------------------------------------------------------------

by fzaninotto at 2011/12/21 09:48:18 -0800

How do streaming responses deal with assets that must be called in the head, but are declared in the body?

---------------------------------------------------------------------------

by fabpot at 2011/12/21 09:52:12 -0800

@fzaninotto: What do you mean?

With Twig, your layout is defined with blocks ("holes"). These blocks are overridden by child templates, but evaluated as they are encountered in the layout. So, everything works as expected.

As noted in the commit message, this does not work with PHP templates for the problems mentioned in the Rails post (as the order of execution is not the right one -- the child template is first evaluated and then the layout).

---------------------------------------------------------------------------

by fzaninotto at 2011/12/21 10:07:35 -0800

I was referring to using Assetic. Not sure if this compiles to Twig the same way as javascript and stylesheet blocks placed in the head - and therefore executed in the right way.

---------------------------------------------------------------------------

by fabpot at 2011/12/21 10:34:59 -0800

@Seldaek: I've just added a `flush` tag in Twig 1.5: fabpot/Twig@1d6dfad

---------------------------------------------------------------------------

by catchamonkey at 2011/12/21 13:29:22 -0800

I'm really happy you've got this into the core, it's a great feature to have! Good work.

@fabpot fabpot merged commit 887c0e9 into master Dec 31, 2011

@@ -28,7 +28,7 @@
*
* @api
*/
class PhpEngine implements EngineInterface, \ArrayAccess
class PhpEngine implements EngineInterface, StreamingEngineInterface, \ArrayAccess

This comment has been minimized.

@b00giZm

b00giZm Dec 31, 2011

Is there a reason why the PhpEngine implements the StreamingEngineInterface just to throw an Exception? Didn't you say that streaming responses are impossible for PHP templates by design?

@b00giZm

b00giZm Dec 31, 2011

Is there a reason why the PhpEngine implements the StreamingEngineInterface just to throw an Exception? Didn't you say that streaming responses are impossible for PHP templates by design?

This comment has been minimized.

@fabpot

fabpot Dec 31, 2011

Member

You are right. This is a nice side-effect of having another interface for streaming. Fixed here: e462f7b

@fabpot

fabpot Dec 31, 2011

Member

You are right. This is a nice side-effect of having another interface for streaming. Fixed here: e462f7b

@igorw

This comment has been minimized.

Show comment
Hide comment
@igorw

igorw Dec 31, 2011

Contributor

I ran into some problems with the way this is implemented. The issues are related to transfer-encoding.

First, it is not possible to force identity (the default) encoding, because StreamedResponse overrides it in any case. It should only set the encoding if none is set yet. Note: Even if it is explicitly set to identity and not overriden to chunked, apache will change it to "identity, chunked" because no content-length is set.

Now this brings us to the second issue. When you send a transfer-encoding=chunked header, apache will expect the content to already be chunked. Of course this is not the case, and thus it does not work. Unless other webservers require it to be present, I would suggest simply not setting the transfer-encoding header. Since no content-length is set, the server should switch to chunked automatically.

Contributor

igorw commented Dec 31, 2011

I ran into some problems with the way this is implemented. The issues are related to transfer-encoding.

First, it is not possible to force identity (the default) encoding, because StreamedResponse overrides it in any case. It should only set the encoding if none is set yet. Note: Even if it is explicitly set to identity and not overriden to chunked, apache will change it to "identity, chunked" because no content-length is set.

Now this brings us to the second issue. When you send a transfer-encoding=chunked header, apache will expect the content to already be chunked. Of course this is not the case, and thus it does not work. Unless other webservers require it to be present, I would suggest simply not setting the transfer-encoding header. Since no content-length is set, the server should switch to chunked automatically.

@igorw

This comment has been minimized.

Show comment
Hide comment
@igorw

igorw Dec 31, 2011

Contributor

Nginx does not have that problem. But: Proposed solution confirmed working with nginx 1.0.5.

Contributor

igorw commented Dec 31, 2011

Nginx does not have that problem. But: Proposed solution confirmed working with nginx 1.0.5.

fabpot added a commit that referenced this pull request Jan 2, 2012

merged branch igorw/streaming (PR #3017)
Commits
-------

7ae9348 [streaming] Document and test that Transfer-Encoding is absent
83c23ca [streaming] Do not set a Transfer-Encoding header of chunked

Discussion
----------

[HttpFoundation] Do not set a Transfer-Encoding header of chunked for streaming responses

Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes

This is an adjustment to the streaming introduced in #2935.

Apache expects the response to already be in chunked format when the Transfer-Encoding header is set to chunked, which causes it to not deliver the streamed body.

If no Content-Length is set on the response (regardless of Transfer-Encoding), web servers will automatically switch to chunked Transfer-Encoding, and handle the chunking for you.

I have tested this with Apache 2.2.2 and nginx 1.0.5. Testing with other webservers is appreciated.

akucherevskiy pushed a commit to akucherevskiy/silex_auttaa that referenced this pull request Jul 26, 2014

merged branch igorw/stream (PR #229)
Commits
-------

8dd779e [stream] Fix rst formatting
73fe0b1 [stream] Add a nice API for streaming responses

Discussion
----------

[stream] Add a nice API for streaming responses

This PR adds a nice API for creating streaming responses with the new StreamedResponse class that was added to symfony [just recently](symfony/symfony#2935).

Usage is documented in the usage doc, but for lazy people:

```php
<?php

$app->get('/images/{file}', function ($file) use ($app) {
    if (!file_exists(__DIR__.'/images/'.$file)) {
        return $app->abort(404, 'The image was not found.');
    }

    $stream = function () use ($file) {
        readfile($file);
    };

    return $app->stream($stream, 200, array('Content-Type' => 'image/png'));
});
```

Note: I had to point the autoloader to a copy of symfony/symfony because the subtree splits are not up-to-date. Thus the vendors are out of date too right now.

nicolas-grekas added a commit that referenced this pull request Oct 19, 2017

bug #24626 streamed response should return $this (DQNEO)
This PR was squashed before being merged into the 2.7 branch (closes #24626).

Discussion
----------

streamed response should return $this

| Q             | A
| ------------- | ---
| Branch?       | 2.7
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | may be yes?
| Deprecations? | no
| Tests pass?   | yes
| License       | MIT

---

`sendHeaders()` and `sendContent()` should return $this,  as in the parent class.

related PRs:
#2935
#20289

Commits
-------

058fb84 streamed response should return $this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment