You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
http://localhost/myendpoint?test=what&test=what2 -> this is a valid request. So the query option test can exist one or multiple times. Which makes it a string AND an array... Although this is not handled by sf ATM. I have another app written on another lang that I would like to migrate to sf at some point.. was hoping that in the future sf will add support for the feature above but I see it is moving towards to the opposite direction.
Now you are defining the behavior. I mean before the behavior was in the hands of the programmer. If he didn't check that it is an array it was it's own bug therefore a 500 is fine.. now why to throw an exception?
For instance how is someone supposed to handle now this? (which I do have cases like this, yea I know they suck a bit)
Let's say we are on sf6... should the developer add a try catch using get and then if an exception is thrown use the all function. It seems a little bit not worth it..
Furthermore what was the motion behind this PR...? Was this something commonly reported that should've been fixed? IMHO it was working fine as it was and the strictness there is not needed.
The text was updated successfully, but these errors were encountered:
AFAIK, in PHP, test=what&test=what2 is always string as the latter overwrites the first.
The motion is to have 400 response instead of 500, when users tempers with the query params. As the app may unexpectedly receive an array leading to all sorts of crashes (given a string is expected/assumed).
To get the raw value, thus string|array use all()['key'].
Symfony version(s) affected: 5.1.0
Description
Hi this is a followup of this: #34363
http://localhost/myendpoint?test=what&test=what2
-> this is a valid request. So the query optiontest
can exist one or multiple times. Which makes it a string AND an array... Although this is not handled bysf
ATM. I have another app written on another lang that I would like to migrate to sf at some point.. was hoping that in the futuresf
will add support for the feature above but I see it is moving towards to the opposite direction.500
is fine.. now why to throw an exception?For instance how is someone supposed to handle now this? (which I do have cases like this, yea I know they suck a bit)
http://localhost/myendpoint?username=what
http://localhost/myendpoint?username[]=what&username[]=what2
Let's say we are on
sf6
... should the developer add a try catch usingget
and then if an exception is thrown use theall
function. It seems a little bit not worth it..Furthermore what was the motion behind this PR...? Was this something commonly reported that should've been fixed? IMHO it was working fine as it was and the strictness there is not needed.
The text was updated successfully, but these errors were encountered: