RFC Send Response Workflow

[prolic]

see: http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Send+response+workflow

[weierophinney]

The changes in this file are backwards incompatible and cannot be made in ZF2.

[weierophinney]

I've also left comments on the RFC, @prolic

[prolic]

This also fixes a so far unknown issue: If your controller returns a custom response object (e.g. return new StreamResponse), this response object was not set in Zend\Mvc\Application and also not updated in Zend\ServiceManager\ServiceManager. When you call $serviceManager->get('Response') after returning a custom response in controller, you will now get the correct response object. (see changes in Zend\Mvc\Application)

[weierophinney]

I wouldn't track this in the response. I'd instead do a hash map of splobjectid => flag -- you can then check the given $response object against that to see if it has been sent.

[prolic]

About headers_sent():

@weierophinney how do you think we should handle this? After calling "header($someHeaderString)" there are still no headers sent and "headers_sent()" returns false. Headers are sent, when content gets sent, too. When we change the implementation to use "headers_sent()", it would no longer mean, that "header($someHeaderString)" was called.

[prolic]

RFC document at http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Send+response+workflow needs to be updated. However the open questions remain:

• How and should we use headers_sent() ?
• Should we also be able to send Zend\Http\Response or only support sending of Zend\Http\PhpEnvironment\Response ?

[weierophinney]

@prolic re: headers_sent() -- I'd use a two-step approach:

1. First, check the status of headers_sent()
2. Second, check if we've sent the headers from this specific Response object before (this is the bit where I recommended keeping a hash map of the SplObject ID/sent status in a previous comment).

Basically, headers_sent() only returns true if we have also started sending content. So the first check is for that -- because you'll get a PHP notice if that's the case, and we don't want that. The second check is to ensure that if the same object is passed to the routine again, we don't try and send the headers a second time.

[weierophinney]

Why is this needed, exactly?

[weierophinney]

@prolic So, only one question really remains in your list: if we should allow sending alternate Response types. My answer is yes. There are a couple ways to manage this:

1. We have the ResponseSender delegate to different methods based on Response type
2. We use an event, and allow attaching to that event. This way, we can provide some standard listeners for known Response types -- Console, PhpEnvironment, Stream -- and the first one to report having sent the response causes the event to stop propagation.

The first is easier and faster to implement, but less flexible. The second will take more time, and require more objects, but be completely flexible.

[prolic]

@weierophinney thanks for your input. I will update this PR and the RFC document tomorrow.

[prolic]

updated worflow, document still out of date, see last commit message

[prolic]

todo: add stream response sender, write tests

[weierophinney]

@prolic Let me know when this is ready to review again.

[prolic]

I will add the stream response sender in a separate PR, as there is probably more to discuss. All tests are running again. Ready for review.