Add method to prevent sending of response after action completes

[colinmollenhour]

Magento needs some way for a controller action to output and then signal the router to not attempt to send headers. There are cases like the wysiwyg thumbnails that generate "HEADERS ALREADY SENT" errors in the logs because the headers were sent by dynamic image output. I manually added an "exit;" inside the controllers to prevent this in production but there should be a more graceful solution since "exit;" prevents the use of event observers that are dispatched after the controller action. For example:

$this->getResponse()->disableOutput();

[stalniy]

I think there will be useful to create StopDispatchingException (throw it intstead of calling exit function) and NotFoundException (throw it when you want to forward user to page404)

[colinmollenhour]

@stalniy there is already a method for 404 pages:

$this->_forward('noroute');
return;

As for the StopDispatchingException, you didn't explain what the advantage of using exceptions is exactly in this case.. Typically exceptions are used to indicate errors, but the uses for disabling the output don't necessarily involve errors so I think disableOutput() is just as good. A programmer might be thinking.. "Ok, I've rendered the image, now I need to disable the default response output.". The proposed method clearly fits this need whereas I would argue a "StopDispatchingException" is counter-intuitive and vague. E.g., what happens when you throw that exception, does it output any http status codes or headers? Will an error be logged somewhere? Will the exception even be caught and handled? Will any further events still be dispatched? Also, how would the programmer know of the existence of this exception? By using a method of the response object, the method can easily be found by the IDE or by looking at the code for the response class, but exceptions with special names for special purposes are arguably not easy to discover.

[stalniy]

I knew about $this->_forward. It had better use exception instead action method. Because, for example, in production mode system can forward user to 404 page and on dev mode can show some debug information (exception back stack, etc.). What will you do if you forwarding logic is wrong? With exception in dev mode you can check back trace and be sure everything works in a right way.

Sometimes you need to stop program execution. For this purpose in Magento everybody uses php function "exit". It's not a good way. So, StopDispatchingException is thrown when you want to stop action flow. And it's obvious it will have catched outside action.

Typically exceptions are used to indicate errors

It's not exactly. Exceptions are used to indicate special places in program, not just errors!

[colinmollenhour]

I still disagree, but feel free to open your own pull request that adds exceptions. :)

[stalniy]

Symfony framework are implemented in such way. My proposition is just another way of implementation the issue that was discribed by you. So i think it's not necessary to create anothe issue.

[colinmollenhour]

Magento is not Symfony. Magento uses exceptions almost exclusively for error handling (I can't even think of an example where exceptions are used in a non-error context) so it makes sense to stay consistent with the rest of the framework. If they change Magento 2 to use exceptions for all sorts of status passing schemes (@magento, PLEASE DON'T!) then your proposal would be appropriate, but they haven't.

Please feel free to continue pushing your opinion by creating your own pull request. An issue is not a pull request. A pull request is: fork magento2, write code, make commits, create pull request. An issue is: jot down a poorly organized thought and click submit. It is frankly a waste of my time to continue discussing this because your proposal lacks a real implementation (e.g. pull request), so I won't be discussing further. Sorry to be so blunt.

[stalniy]

@colinmollenhour
ok=) Do you know why your suggestion is good and why it is bad?
Good:

• easy to implement
• easy to use
• easy to understand
• flyweight way for implementation but not extendable

Bad:

• not universal, if you want to add some another behavior you will add another flag to Response class, then you class will have a lot of flags and methods (that do some work).
• not logical. Response object must give some result to user, so it's not logically to have method like disableOutput, because you return output to user but with help of another function/method!

ok then about my suggestion.
Good:

• OOP way
• tested way by another framework
• if you need to add some another behavior you will create another exception class and add catch block
• logical way to use Exceptions (Exception != Error). Code of response class is clear

Bad:

• hard to implement
• need to create exception class for each special behavior

I understand you but it's a quite stupid to write something like "PLEASE DONT DO THIS".
I'm just trying to be objective maybe i'm wrong and it's ok.

[colinmollenhour]

I just wanted to make it clear that I was in no way advocating that Magento start using exception classes for status passing. A framework needs to be cohesive and establish it's own conventions and abide by them. Using special-case exceptions is not one of Magento's established conventions (for good reason), so it doesn't really matter which approach is "better", it matters which approach best fits the Magento "way". Creating an exception class named "StopDispatchingException" is the Symfony way, it is not the Magneto way. We agree on this, don't we?

[magento-team]

@colinmollenhour
@stalniy
We deem that both proposed solutions attempt to cure symptoms, rather than the root cause.

In Magento framework, the class responsible for sending output of a controller is the front controller. Controllers, not to mention models or ther application layers, should not send any output directly.
We must admit that the cases where there is output sent directly and/or program is terminated are inconsistent with our own approach.

So we have added to the tasks backlog refactoring of such places across the board. The particular case with images in WYSIWYG has been fixed (will be rolled out in one of next code updates updates). We are considering to disallow on framework level direct output by controllers -- ob_start() before dispatching and ob_end_clean() after dispatching, so that there would be no incentive to do direct output.

And thank you for the valuable report and open discussion. You're raising important issues.

[colinmollenhour]

I agree that it would be best to avoid direct output whenever possible, but in the case of dynamic file output this could introduce some doubling of required memory. For example if I have a script that generates a 100mb file and it outputs it directly, but I have to store that output in the interim, I'll be using 200mb of memory to do so. PHP's readfile() is an efficient function for streaming large files from disk to the output, but without direct output this couldn't be used so downloading a 1GB file would be impractical. I really don't think direct output should be permanently disabled. Perhaps just disabled by default to promote good practices?

[magento-team]

Good point. We have added a note to take it into account.

The memory issue you described, it could be solved, for example, by implementing a "lazy load" pattern: instead of a string, set an object to the response output. The class of that object could implement __toString() and so flush the file upon request.

That may require some refactoring of the HTTP-response class.

[colinmollenhour]

Nice, I hadn't thought of the __toString magic method for this purpose. That might be a viable solution, but I think some image libraries also set headers at the time of rendering such as the content-type or encoding perhaps. Just something to keep in mind for the final design. Thanks!