Trying to get a 413 results in decent user message

[parijke]

Laravel Version

11.26.0

PHP Version

8.3.12

Database Driver & Version

Postrgres 15

Description

When trying to handle a 413 error, thrown by the ValidatePostSize middleware like described here does not seem to work.
https://laravel.com/docs/11.x/errors#customizing-the-exception-response

It appears that the session is not started (yet).

Steps To Reproduce

Create a handler for a 413 error response like https://laravel.com/docs/11.x/errors#customizing-the-exception-response

Post a huge file to a form. No error is shown.

[parijke]

Created a small reproducer
https://github.com/parijke/laravel-test-session-exception

[crynobone]

Don't see that the reproducing repository uses ValidatePostSize? https://github.com/search?q=repo%3Aparijke%2Flaravel-test-session-exception%20ValidatePostSize&type=code

[parijke]

It uses it under the hood and is a default middleware. The PostTooLargeException is throw by it

[crynobone]

https://github.com/search?q=repo%3Alaravel%2Fframework%20PostTooLarge&type=code

PostTooLargeException is only thrown frommValidatePostSize middleware. This middleware is not included by default, so unless your applicate explicitly append this it will not be used in your application.

[parijke]

It actually is included by default... see reproducer

[Jubeki]

Hey @crynobone, I also think it is included by default in the global middleware stack:

framework/src/Illuminate/Foundation/Configuration/Middleware.php

Lines 403 to 419 in bc5bd66

	/**
	* Get the global middleware.
	*
	* @return array
	*/
	public function getGlobalMiddleware()
	{
	$middleware = $this->global ?: array_values(array_filter([
	\Illuminate\Foundation\Http\Middleware\InvokeDeferredCallbacks::class,
	$this->trustHosts ? \Illuminate\Http\Middleware\TrustHosts::class : null,
	\Illuminate\Http\Middleware\TrustProxies::class,
	\Illuminate\Http\Middleware\HandleCors::class,
	\Illuminate\Foundation\Http\Middleware\PreventRequestsDuringMaintenance::class,
	\Illuminate\Http\Middleware\ValidatePostSize::class,
	\Illuminate\Foundation\Http\Middleware\TrimStrings::class,
	\Illuminate\Foundation\Http\Middleware\ConvertEmptyStringsToNull::class,
	]));

[Jubeki]

@parijke could you also check if your web server has a restricting limit for post / file size in the php.ini or the nginx configuration:

• upload_max_filesize
• post_max_size

[parijke]

The issue is not that I cannot set those values. The issue is that I cannot create a decent user message because the session is not started yet, while the documentation says this should be the way

[Jubeki]

The session is not started, because the session start is in the web group.

First run the global middleware and then the web middleware. Because ValidatePostSize runs before Starting the Session, the session of course is not started yet.

Can you show me, where in the docs it says, that the session is already started?

[crynobone]

My bad @Jubeki @parijke

ValidatePostSize should be executed earlier than other middleware because if it does exceed max_post_size all values from $_POST and $_FILE superglobals will be missing. It seems like the example in the documentation is only useful for any exception occurs after StartSession middleware.

[parijke]

The session is not started, because the session start is in the web group.

First run the global middleware and then the web middleware. Because ValidatePostSize runs before Starting the Session, the session of course is not started yet.

Can you show me, where in the docs it says, that the session is already started?

It doesn't state in the docs that it is started... it is implicitly because of the 419 example in the docs.

My point is if it should be considered to start a session before the ValidatePostSize middleware, as the post is almost certainly a user action? Just wondering....

[Jubeki]

A session is only used for browsers with cookies. You don't want to start a session, if you use for example API-Tokens, which are stateless.

That is the reason for the web and api middleware groups. global always run, the other depending for who the endpoint is intended for.

[parijke]

That sounds reasonable... not sure how to handle this into a form validation then. Any ideas?

[Jubeki]

Did you try catching Illuminate\Http\Exceptions\PostTooLargeException inside the render/report method? This is the exception which will be thrown by the middleware and probably be converted into the error page and status code 413.

[parijke]

@Jubeki Maybe I misunderstand, but this is in the same WithExceptions in the app.php, isn't it? Therefor, still no session is available to set the errors on.

Or do I mis the point here?

[Jubeki]

Sorry my bad, I now understand, that you want to write data to the session, a validation error, or another message. Yeah that is not possible in that way.

You could of course catch the PostTooLargeException then Start the Session manually, but this would be quite a workaround and I am not sure if that would be the best way to achieve your desired behaviour. (I am not sure how you start the session manually, but taking a look into Illuminate\Session\Middleware\StartSession could be worth while. You also have the option to write your own ValidatePostSize Middleware.

[parijke]

I managed to get it working by setting the priority of the middleware. See the latest commit in the reproducer.

What I cannot predict are the possible disadvantages. Any ideas?

[MKodde]

The 'disadvantage' here is that only the web namespace pipeline uses the 413 middleware. The api pipeline would still need it right? So instead of adding it globally, the default config might need to be adjusted to add it in the right spot for both use cases?

[parijke]

That is correct... If we ever need it in any of the other namespaces, we have to set it there explicitly as well

[MKodde]

I kind of meant that the default Laravel setup should do this.

[parijke]

It appears Symfony does more ore less the same.

https://github.com/symfony/symfony/blob/7.2/src/Symfony/Component/Form/Extension/HttpFoundation/HttpFoundationRequestHandler.php#L71