TYPO3 Core

Not sure I understand, but - the initialize Actions are not like the "normal" actions, in which a ResponseInterface object is returned, and thus forward/redirect responses can be emitted.

The Exception always stops the flow directly and ends the middleware, which is why its usually used to throw distinct json/download returns, or abort a workflows with errors. So I'd say "yes, its intended behavior to deal with in an initializeAction" (personally).

So maybe you want to make the initialize action set some arguments, and in the normal createAction you would check on that and use the real "return" there, if that feels improper.

Is the link you gave not working, I might not understand what the actual problem might be in this scenario. I understand it works, but you wonder why, is that right?

Maybe come around to the slack #typo3-cms channel and we could try to elaborate, because a back/forth in forge here may take some time ;)

Thanks for yout offer. :-)

Did that and explained a little bit more about the situation

https://typo3.slack.com/archives/C025BQLFA/p1729077330854969

We had a small chat about this. Major take-aways:

- initialize*Actions are meant to be executed before the ViewInterface and the property mapping took place, so they can influence that process
- that means, they can not do "normal" redirects or forwards like regular *Actions can (due to argument mapping and view context). So it is right that a forwardReponse executed in the initialize*Action context does not know anything about a possibly "body".

So you have to either manipulate arguments in the initialize*Actions and then evaluate them in the regular actions, and do errorhandling on a view basis (or forwarding for that matter).

OR you can use the PropagateResponseException to make the whole URL request workflow stop, and perform a redirect with cleaned/adjusted arguments. That will affect the rendering of any other extbase plugin on the same URL though. But since your action is evaluated, that means the context is set to your own action, and you are able to make that decission for the whole workflow.

Note that a redirect should possibly evaluate all other request URI options (GET/POST) that are NOT related to your own extension (like typeNums, URI args outside the chash-scope, etc.) and be sure to transfer those to the "scrubbed" request as well. Ensure you do not create any URL parameter decoding/encoding and pass the input arguments back raw how they were passed to the $this->request context for the uriBuilder of the redirect.

You can use the responseFactory to pass a fresh response with all the arguments you need to the propagateResponseAction of course.

Note that this "propageteResponseException" handling is labelled "internal". It is a workaround until PSR-7 request handling is cleaned up properly, because for now while the initialize*Actions have been freed of "bad context", there is no "proper way" yet to handle the bubbling/interception differently than this exception.

I made a demo/dummy extensions https://github.com/garvinhicking/extbase-redirectforward-example that tries to showcase the options you have at disposal.

Please let me know if that works out for you and if that can close this issue. :-)