Trying to get a 413 results in an empty 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?