How do you handle error pages

[wizzymore]

I am currently battling with Livewire and the session middleware because I am sharing the app layout with the following error pages: 404, 401, 403 and 419 and i have a question.

How do you handle this pages? Is there a good and intuitive way to include the session in this side of the application?
I don't find the normal "laravel" way to be very intuitive.

Like, i am having a lot of issues getting the session to work in those pages, i know i can just move outside of the 'web' group and make them global, but this is beating the point as this means that i will try to start a session for each api call on my app that is stateless.

So is there a better way to make this errors be part of the app? I already managed to fix the 404 page ( for a route that is not matched in my application ) using a route fallback, but how can i make the normal error pages work normally?

[wizzymore]

Bump...

[mbabker]

Don't use your main app template as the base template for your error pages. I treat error pages as something that should both have a minimal output and use minimal services from the application (especially in the case of 500 range errors).

[wizzymore]

For the 500 errors you can't display the app template as the error can happen in multiple places, even before authentication or the bootstrap of the stuff needed for the app template.

I don't use the app template in 5xx errors for that reason, i use a custom minimal template.

My question is mostly about the 4xx erorrs as there is no reason in those pages for the session to not work without having to move the session outside of the web middleware.

[mbabker]

It depends on when the 4xx error was raised, too. If a 4xx error is raised in a middleware before the session is started (out-of-the-box, the ValidatePostSize middleware can do this), then that would make the session data unreliable in the context of preparing an error response.

If the 4xx error is coming from a route with a middleware group that does not include sessions at all, that too would make session data unreliable (to me this sounds really flaky if you need the error handler to have different behaviors based on how far in the request cycle things got before a 4xx error was raised).

In general, I would just avoid using anything more than the minimal bits needed to render an error, regardless of it being 4xx or 5xx.