BUG: Headers added on error pages are not sent to client

[Benjamin-K]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

If you add headers in fusion or in a middleware to your error pages (Status Code = 404), those headers are not sent to the client.

In a middleware, all code after $next->handle($request); won't be executed.

Other changes (like adding an attribute to the html tag) work as expected.

Expected Behavior

Adding headers to error pages should work through fusion or a middleware.

Steps To Reproduce

1. Add a new document/page on the first level of your site with uriPathSegment = 404 (or use existing error page).

2. Add the following code to your Root.fusion file in your site package:

   // This part could be skipped, if you have an existing error page
   error {
       @context.notfoundDocument = ${q(site).children('[uriPathSegment=404]').get(0)}
   
       4xx {
           @position = 'start'
           condition = ${statusCode >= 400 && statusCode < 500 && notfoundDocument}
           renderer = Neos.Fusion:Renderer {
               @context.node = ${notfoundDocument}
               // type = ${q(notfoundDocument).property('_nodeType')}
               type = 'Vendor.Site:Document.NotFound'
               renderPath >
           }
       }
   }
   
   // IMPORTANT: Add httpResponseHead.headers with a custom header to your error page
   prototype(Vendor.Site:Document.NotFound) < prototype(Neos.Neos:Page) {
       httpResponseHead.headers {
           X-Custom-Header = 'My-Test-Value'
       }
   
       // Optional, just for demo
       body >
       body = 'This is my error page'
   }
   

3. Open browser with an open developer console.

4. Visit any unknown url that will trigger the error page to be rendered and view the returned http headers.

Environment

- Flow: 8.4.2
- Neos: 8.4.2
- PHP:  8.4

Anything else?

No response

[Benjamin-K]

I did some further investigation here.
The Neos\Flow\Http\RequestHandler will call the middleware chain. But if a 404 page is requested, a Neos\Flow\Mvc\Controller\Exception\InvalidControllerException is thrown and the rest of the code is not executed any more. I couldn't figure out, where the exception is catched. Does anybody know, how exceptions are handled in that case?

[Benjamin-K]

Update, as @kitsunet mentioned on slack:

\Neos\Flow\Error\ProductionExceptionHandler::echoExceptionWeb  will grab the exception as the registered exception handler (production context, dev has a separate but siimilar one), this checks for a view configuration based on the exception status code. neos overwrites this to a FusionExceptionView via settings for 404 for example. Either way the exception handler directly outputs the results instead of passing it up the middleware chain again.

For Neos, the exception handler is the FusionExceptionView. Neither Neos\Neos\View\FusionExceptionView (for Neos) nor the ProductionExceptionHandler render any headers.

As no middleware is called again afterwards, no additional (security) headers can be set. Any idea how to fix this?

[Benjamin-K]

Update: The FusionExceptionView receives the headers as plain http response and strips them away. If I knew, when the exception is caught, I'd try to capture it sooner and keep the existing middleware chain. Then, all headers set in a middleware will be correctly added and both, the FusionExceptionView and the ProductionExceptionHandler (and maybe others) could/should return a ResponseInterface passed to the middleware chain.

[mhsdesign]

Thanks for the writedown. That the middleware does not apply seems correct as we fully existed the chain. And yes the currently the ProdExceptionHandler only cares about the body of the response. But in Flow 9.0 we already refactored parts of the response handling actually allowing to emit the headers as well in the ExceptionHandler. The required logic just needs to be added here:

https://github.com/neos/flow-development-collection/blob/9bb513355c60dc671751781730f0f4f4242c49f3/Neos.Flow/Classes/Error/ProductionExceptionHandler.php#L44-L50

In 8.x this would also be fixable to look into how new ActionResponse() got mutated see line 167 after rendering the view.

A quick fix for your project at hand might be to extend the FusionExceptionView or hack into somewhere to manually use the header() function.