I suggest changing that only for getPayload.

toArray is only doing json-decoding, and an empty body is not valid json.

i consider toArray / getPayload equivalent public API :)

i mean, from the original issue, a throwing $r->getPayload()->get('key') would be equally annoying as a throwing $r->toArray()['key'] 🤔

perhaps both POVs are equally valid, let me know if we prefer a getPayload specific solution 👍

toArray is only doing json-decoding

it's kinda an implementation detail ;)

@ro0NL if you don't know that the body is valid json, toArray might still throw for something else than an empty body. So I don't see how this changes much things.

note that HttpKernel will automatically convert those exceptions to a 4xx response.

it enables doing if ($r->toArray()['key']) over if ($r->getContent && $r->toArray()['key'])

if the request content is actually corrupt, let it be bad JSON, then we should throw (which hasnt changed here)

my point here is, toArray/getPayload should not be used for state checking IMHO, but a route/controller condition should

@ro0NL if your endpoint expects JSON, sending an empty body is actually a corrupt request.

im still not sure toArray conveys your endpoint expects JSON, at least not by its name 🙄

to me, and if i recall it correctly, it was designed to be an implementation detail

btw, see also #50492 (comment) 😅

TLDR: toArray to me is a poor-man getPayload solution, and should have been deprecated

@ro0NL we explicitly decided not to deprecate it immediately to make things easier for the ecosystem needing to support multiple version of Symfony.

I would expect us to deprecate it in 7.1.

Gets the request body decoded as array, typically from a JSON payload

to me proves JSON is an implementation detail

in that sense the method is already bugged for not returning $_POST

im gonna wait for toArray deprecation, so we can avoid this debate

@stof

I would expect us to deprecate it in 7.1.

we should get rid of it