Error Page httpResponseHead.statusCode overridden to 404

Using Neos & Flow
1

We have an error page in which we replace the 404 page with a 410 when the page has a hiddenAfterDateTime less than two weeks in the past.

In the error page we set the status code to 410 correctly using the httpResponseHead.statusCode = ${statusCode}

As far as I can see this is reset in the Neos\Flow\Error\DebugExceptionHandler->echoExceptionWeb lines 64-68

Currently in the normal fusion views the status codes set in the httpResponseHead are respected, where would I need to look in order to port this functionality over to the error case?

2

That’s indeed a tricky problem, a gotcha between using fusion for the error view and the excepectations of an exception handler. Ultimately I think the exception handler should have the authority over the status code, so you would have to either adjust the exception if possible or create your own exception handler that no longer overrides it.

Surely something to look into closer from our side (maybe a check if a status code is already provided by the view).

3

@christianm I am not so sure I agree with you 100% here, I would argue that the response is not built by the Exception, the exception can provide the default or “recommended” response code, I agree with you there. If this is not overridden by some other more specific case, but the error fusion is in this case like a “catch” which can then choose how the error should be handled for the user.

4

Since “not found” is a perfectly valid result I really dislike using an exception for that. How about using a “not found” http component at the end of the http middleware chain to render the 404 result.

Would be quite a change for Neos and Flow and almost surely breaky.

However this component would still have a hard time to figure out wether the document has been hidden more the 14 days ago.

5

I agree. And – although I violated this rule myself in the past – we should avoid exceptions for control flow in general. It is error prone and slow.

I think that’s a great idea!

I would consider this usecase a little bit too edgy to implement it in a core middleware. But the Redirect handler package can cover this case IIRC.

6

I think you are correct here, however if the error pages are managed by a middleware then edge cases could be handled by higher priority middleware without too much trouble.